EatVacuum

And here it is... http://forum.kerbalspaceprogram.com/threads/78067-0-23-5-Research-Them-All-1-1-%28April-30%29

I know it's moot for most people now but would you consider making the tank cost proportional to the length of the tank? Some of us play with mods like Kerbal economy so we are spending to build our rockets. And it would give PP a headstart when full campaign mode arrives. Stretchy SRBs was great as it let me chop dozens of parts and save RAM but the tanks are too expensive when you just want a short one. Thanks a heap though either way, I love all the procedural addons.

Nope, after looking at both, this one seems to raise the low end I.e. make the darker scenes lighter. The other just raises the light level at all levels. Thiz one seems much better thought out. Kudos

When you look at your "hours in game" on Steam and realize it's more time than you spent at work in the ten months since you bought the game. Or slept...

I'm thinking Fireball XL-5 or one of the other Gerry and Sylvia Anderson puppetmation shows. It's been a loooong time...

I'll take a look, thanks

Okay I already understood what flaps and spoilers are. Airbrakes and wheel brakes both activate when you use to the brake keys. But what key activates the flaps?

Conics mode 0 shows your path within each SOI relative to the current position of the planet/moon generating that SOI. It's useful for visualuzind and planning your approach or fly by of a body. Conics mode 1, the default shows the entry point of the conic for your next SOI connected to the point where you enter the next SOI. All of the comics draw modes are explained pretty well, with pictures, here... http://forum.kerbalspaceprogram.com/threads/11322-Different-Conic-drawing-modes

Skylon has an orbital maneouvering system seperate from the Sabre engines that it would be using for most of it's time in space. If those align better with the nose direction then I don' t think you have a big problem with the Sabre thrust being slightly skewed. Of course since the OMS and Sabres don't align that means one or the other would always be a problem. Other than putting in two differently aligned probe bodies I don't see how to fix this and that doesn't seem ideal either.

More accurately and so the entire point of SABRE - it goes up to Mach 5 or so in air breathing mode. Then it switches over to close cycle mode and uses liquid oxygen instead of air to get out of the atmosphere and to orbital velocity. So it's truer to say it is designed for Mach 20 or so.

I definitely want dedicated forums for the popular addons. Remotetech has over 300 pages, Interstellar has 500, Ferram, Mecheb and B9 are all in that ballpark. When I'm trying to see If there is a fix for a problem I don't want to search through the last 50 pages of an addon's thread to see if someone has reported a similar problem or a fix. And I also have to potentially check for several seperate related threads posted by users who in the support and requests subforum. The forum search engine is just this side of totally useless and web searchers like Google invariably take you to the OP of the thread. I'd much rather have a seperate subforum for support for those addons and be able to just read thru the threads dedicated to particular issues and requests.

Okay, I'm not a rocket engineer or one of the many very talented mod designers who may read this and scoff, so take pity on me and please only send constructive criticism. But with that proviso, here's my thoughts on how to proceduralize engines. First, divide the procedural engine into three parts - the shrouded portion of the rocket engine, the exposed portion of the engine and the nozzle (or bell). By breaking the engine up it is possible to produce a larger number of variations with a smaller number of models. To produce 27 rocket engines could require 27 models if each is made as a unit, and as well, they might not rescale well as bigger engines should look beefier and would require more detail than smaller ones to look good. On the other hand, 3 shrouds, 3 motors and 3 nozzles, a total of nine models, also allows for 27 combinations ( 3x3x3 ), i.e. 27 different rocket motors. I think, again not being an expert or even overly familiar with the code behind the various procedural parts mods, I would think breaking the engine into a couple of simpler parts would also simplify any procedural rescaling of parts. My reason for breaking them up into shrouded and exposed motor and nozzle rather than some other selection is as follows; Considerations for the Engine Parts For most rockets, most of the rocket engine is actually inside a shroud or within the rocket fuselage itself. KSP fuel tank volume seems to be calculated on the complete volume of the fuel tank, not allowing for any noticeable portion of the internal space to be taken up by the rocket engine. So there is no penalty to having a big rocket attached to a tank, and no advantage for a smaller one. Adding a shrouded part seperates out the rocket motor volume from the fuel tank, while at the same time limiting he number of models that have to be made to reflect a large number of potential different rockets. Resizing these mostly cyclindrical or perhaps slightly flared or tapered parts would seem to be well within the capabilities already demonstrated by Stretchy SRBs, and similarly a relatively small number of textures would be required to match stock, KW Rocketry, Nova Pulse, NASA or Soviet styled fuel tanks. The exposed portion of the engine could be as simple as an adapter plate to allow single or multiple nozzles to be attached. More elaborate models would only be required for engines that have a significant amount of exposed engine components. In rare cases, an engine could be totally exposed in which case the shrouded portion might be foregone and the engine attached directly to the fuel tank. The option for multiple connectors might need to be applied to the shrouded part as well as single or multiple exposed engines might want to be simulated, not just multiple nozzles. The maximum possible thrust that would be generated by the engine could be calculated based on the volume of the shrouded and/or exposed components as appropriate. The thrust could be modified to be lower for early tech engines and higher for later tech to reflect improved design, miniaturization of parts and better materials science. The size of the nozzle (see below) would be a limiting factor - a given size of nozzle can only handle so much exhaust. The maximum possible Isp of the engine is defined by the fuel used - no amount of technological advance in the rocket engine can increase the Isp for a chemical rocket, poor design can only reduce the actual Isp below this. KSP however uses a generic liquid fuel plus oxidizer (LFO), so to simulate the less efficient earlier fuels like alcohol or kerosene +LOX (theoretical ISPs of 360s or lower) vs later fuels like Hydrogen+LOX (Isp 450s or so), early technology rockets should have a lower Isp built in. Even if Squad were to implement multiple fuels, or if an add on like Real Fuels is used, it would still be appropriate the reduce the earlier tech engines' Isp's to some degree to reflect less efficient design, however the Isp of the fuel would be the more significant factor. For nuclear thermal, plasma and such like engines, the Isp is defined by the maximum working temperature of the nuclear engine or power plant, the efficiency of heat transfer to the propellant and the molecular or atomic weight of the propellant itself. But again, the power would be proportionate to the volume and tech level. Considerations for the Nozzle parts The rocket nozzle is almost always a simple straight or slightly belled cone (ignoring aerospikes for the time being). Generally, the only noticeable elaboration to the bell is whether or not it has a gimbal mechanism at it's base, and likely that it is wrapped in a helical coil of piping that delivers coolant to the bell to prevent it from melting. Resizing the bell, essentially a cone, should be no more complicated than resizing the conical adapters already being done by Stretchy SRBs. The proportion of width to length of the bell will vary depending on whether it is optimized for use under standard sea level atmospheric pressure, in a vacuum or at some pressure level between the two. While this could probably be handled procedurally, it might produce some odd affects for the gimbal or coolant pipes if taken to extremes. Perhaps the gimbal should be moved to the engine portion rather than the bell to prevent this? The reason why the proportions of the nozzle can vary are because if the bell is too short, it is inefficient because the exhaust gas doesn't have time to expand enough, if it is too long the exhaust jet can separate from the nozzle, which also reduces efficiency. The optimum length of the bell increases as the ambient atmospheric pressure decreases. The consequences of either type of inefficiency is lost thrust and so effectively reduced ISP. You can read more on rocket nozzle theory here if interested --> http://en.wikipedia.org/wiki/Rocket_engine_nozzle. Anyway, because the length of the nozzle can vary significantly, if not handled procedurally then several lengths of nozzle would be required to reflect the different optimizations, perhaps as little as three - a short wide one for the liftoff stage, a longer narrower one for use in space and one in between for those optimized for an intermediate pressure. The thrust or ISP changes for the engine would need to be reflected with a "pressure curve" not that different that the velocity curves currently reflected in some KSP engines. This curve would have to be created programmatically to reflect the efficiency at various pressures which in turn would be determined by the length of the nozzle. I assume that this would have to be handled by a plugin that could analyze the nozzle measurements being created by the player. There is one more complication for nozzles - at higher tech levels it should be possible to have nozzles that adapt to maintain optimal length for the ambient air pressure. One method of doing this is to have a nozzle that extends in order to maintain the optimum length as pressure reduces, as has been done in the NK-33. This would be reflected by a more forgiving pressure curve, and it should be reflected in an engine animation, which I think would take it out of the bounds of a procedural engine mod. Aerospike engines avoid the problem of optimum nozzle length changing as ambient pressure decreases. From what I have seen of aerospike engines, they are visually simple, just a cone (or a wedge for linear aerospikes) narrowing to a point, i.e. the reverse of a normal nozzle which widens. Any coolant piping is on the inside to maintain a clean exhaust flow, so there is little or no detailing required, which should make them very simple to rescale compared to a standard nozzle. What do you think?

On a recent Mun mission Bob decided to be cool and leap up to the lander hatch rather than climbing up the ladder as Jeb had a few minutes earlier. He missed the handle and fell off, breaking the solar panel he bounced off of, only to get his helmet lodged between the lander body and a sponsonned fuel tank/thruster/landing gear assembly. All the shaking and firing of his jetpack wouldn't get him loose. Jeb flew the lander back to orbit with Bob's head wedged in place, feet dangling perilously close to the thruster exhaust. Once they docked with the command module, Jeb fired off the radial decoupler sending the gear assembly and Bob tumbling off into space with significant velocity. Bob was recovered some time later but even after a successful trip home he still isn't talking to Jeb.

Jars? Who carries oxygen in a jar? How about in high pressure cylindrical or sperical tanks if it's a gas, cryogenic ones if its a liquid. Or in latex balloons...

Right now Twitch Thursdays are always "blank screen, why do I even try" Thursdays. :-D I usually scan the Daily Kerbal from my smartphone, could that be the problem? Maybe I'll try from home.

There has been an addon that does just this since just after science came out. It's called Kerbal Economy. http://forum.kerbalspaceprogram.com/threads/52915-0-22-Kerbal-Economy-1-1-1 It adds a bit of challenge to do more with less but that adds to the fun. A failed mission becomes a significan failure, you think about designing ships economically. No more building rockets with 7000 m/s delta ve to go to the Mun. You recover the value of returned ship parts so it rewards reuse. You can also adjust the difficulty by changing the exchange rate of science for $$$. I've enjoyed this mod, so I'm really looking forward to seeing how the economy will work in .24. In the meantime, give this a try until .24 comes out.

I have Kethane and KSP Interstellar running on my machine, with 34(!!!) other mods as well, including several that are parts heavy such as KW Rocketry and NovaPunch. Plus a handful of my own modded parts and a folder full of welded ones. With them all in place, KSP is using just over 2GB of RAM at startup, so I'm pretty sure I could put B9 Aerospace in on top of that and still leave KSP over 1 GB of ram to fritter away in the inevitable memory leaks. And that still means hours of game play before running up to 3.4GB of RAM usage and then crashing. My secret? I use the aggressive version of the Active Memory Reduction mod... http://forum.kerbalspaceprogram.com/threads/59005-0-23-Release-1-1-Active-Memory-Reduction-Mod And yes, I have a problem. Hello everyone, my name is EatVacuum and I am a modaholic.

Actually. KSP Interstellar takes the radial engine body and retitles it as an Intake Precooler, so if you use KSP it now has necessary functionality. Of course, the functionality is necessary because the dev also added some code to make the Rapier and Turbofan engines oveheat at the extreme high speeds as they do in real life, as you can see from the KSPI code snippet below. @PART[RAPIER] { MODULE { name = ModuleSabreHeating } } @PART[turboFanEngine] { MODULE { name = ModuleSabreHeating } } @PART[radialEngineBody] { @title = Intake Pre-cooler @description = A magnificent piece of engineering that pre-cools the air flow from atmospheric engines, preventing overheating at high speeds. MODULE { name = FNModulePreecooler } } If you do a little reading on the Reaction Engines SABRE engine (the real life prototype that RAPIER is modelled on) and you'll see that while the hybrid rocket/jet engine is innovative, the really big breakthrough they have accomplished is cooling down the intake air. I guess the KSPI dev wanted to inject that element of realism into the game. If that's what your looking for, give it a try, it's an interesting mod. And for anyone who cares, here's some PR about the precooler... It's kind of counterintuitive but to get a jet engine working at high mach speeds, you have to slow down the intake air... so that you can speed it up again by burning it with fuel to produce thrust. The problem is slowing down the air to a usable speed also heats it up too hot, so now you have to cool it down, and it looks like they have achieved that, for the first time. The alternative is something like a scramjet which is another option that has it's own challenges to overcome. Problem is scramjets don't work at subsonic or even low-supersonic speeds, so even if you could get a scramjet to work at high enough speeds to run you out of the atmosphere at orbital speed and then switch to a closed cycle (i.e. rocket) mode, you'd still need another engine for the lower, slower part of the flight. And now I've wasted enough of your time. Go fly rockets or spaceplanes!

Ok, question was asked earlier and not answered. How do I trigger the flaps and or airbrakes. I don't need to be told not to bother using them, I know that option exists, but for the life of me, if I do want to, I don't see how to activate them. Thanks all

I was having the same problem. I'd added the suggested code for WarpPlugin which may have fixed the indicators. But I was also seeing another issue - when the TextureCompressor plugin was in place, the Spectrometer was showing 0 ppm for Uranium abundance, the other two abundance indicators don't list the material or any number at all. But going to the 2-15 version resolved it for me, using the WarpPlugin.tfcg file as is, no mods required. Try upgrading if you haven't got 2-15.

If you're looking to add challenge, Deadly Reentry et al as previously mentioned will do that. If you don't want to kill Kerbals then don't go with a life support mod, but try remotetech since you will only be losing probes. RT will give you a reason to establish a satellite network, which can be a challenge In itself. And because of the progression of communications gear being integrated into the tech tree, it does give you more to think about when spending those science points. It will however limit your expansion - you can't go to Duna with probes for instance until you have comm dishes that will reach that far. You can still send K erbals but you won't be able to transmit the science home. I'll throw out another possibility for a different type of challenge. In vanilla KSP, there is no downside to failure other than your time spent or losing a favourite Kerbonaut. But take a look at the Kerbal Economy mod. It provides a mecanism where you have to pay for your rockets. This means there is a cost associated with vastly over engineered rockets - you need to be economical and efficient with your designs, and a crashed rocket is actually a set back. It does this by deducting 1 science point from your total for every X dollars (Kerbucks?) you spend on a vessel. "X" being a variable you can set, default is $1000. It maintains a running total in a ledger, and when you recover vessels or parts, it refunds you the value of recovered components. So it also gives you an in-game incentive for considering reuseable vessels. SSTOs are harder to design than classic rockets, but they are 100% reusable so this mod gives you a reason to try them.

Maybe this is a noob question, but I'm having a problem with running landers using RT2. I've googled for an answer and scanned through several dozen of these pages to no avail, so now I'm looking for help. What I've done is built a two part probe mission to go to Eve. One part is an orbitter to scan the planet and (hopefully) act as a communication link between Mission Control and the other part, which is a lander. The orbitter has a GX-128 linked to a satellite orbiting Kerbin, which in turn gives it a good, continuous link to mission control, a DP-10, a Communatron-16 and a KR-7. The lander has a DP-10, a Communatron-16 and a KR-7. Initially, I thought I could send them out using just the DP-10s to maintain the communication link when they first separated while I linked the two KR-7's to each other. But that didn't work, so I added the comm-16s to each figuring that maybe the DP-10s don't link to anything but mission control and that having an active, omnidirectional antenna would provide the short range link until I got the KR-7's connected up. But that didn't work either. I can't point the KR-7s at each other before the orbiter and lander part company, so how am I supposed to do this, short of putting a whacking great GX-128 or KR-14 onto my little 1.25m lander? Or sending a half dozen Kerbals in a command ship to Eve to run the lander?

That seems to have done the trick, it installed and didn't hang at the Gigadish like before, And I seem to have the "always on" antenna in career mode. I did get a "potentially annoying malware" warning during the download but both McAfee and Malwarebytes scans showed it to be safe so I think the warning is spurious. It happened for several other adds with .dlls so I think the antivirus software is generating false positives for almost anything executable I download. Much appreciated! I didn't want to lose RT, it adds a level of challenge that I enjoy.

Ditto - loading version 1.2.7 from Spaceport. Games works fine with all my favourite mods added until I put RT in and then it locks at the exact same point kami-sama mentions. I've waited 10 minutes while the "Loading... /RemoteTech2/Parts/Gigadish1/RTGigaDish1" just stays there the whole time. The usual loading hints keep scrolling by, so the game's not frozen, and KSP's memory usage is under 2GB so while I have a fair number of mods installed, it's not running out of RMA. I looked through this thread, but it's a lot of pages, are there any known incompatibilities between RT and other mods since .23 came out that I might have missed? <edit> tried again, deleting RTGigaDish1 and it just hangs up on RTGigaDish2 instead. Mods used - Chatterer, Deadly Reentry, Toolbar, Visual Enhancements, Procedural Fairings, Kerbal Joint Reinforcement, Kethane, KW Rocketry, Mechjeb 2, Novapunch 2, SCANSat, Kerbal Alarm Clock. All most recent version that are listed as .23 compatible.

It takes a lot less fuel to get back to Kerbin from the Mun than it does to go out. Think of Kerbin being at the bottom of a big hole and the Mun being at the bottom of a smaller one. Maybe that's why they call them gravity wells? And to increase the difference in delta vee, when you take off you're losing delta vee to air drag. But coming back air drag is your friend. It helps you shed velocity which saves you fuel you'd otherwise have to burn since you can aerobrake to slow down. The same may or may not be true for trips to the various planets depending on whether they are higher or lower than Kerbin in Kerbol's gravity well. First time you go to the Mun have double the delta vee you calculate that you need for a one way trip and you'll get back with fuel to spare. After that you'll know about how much to cut back for the next trip.