OhioBob

This may be obvious, but also make sure at least one of your crew is a pilot. Scientists and engineers can't control a spacecraft.

Should be OK provided you don't have any craft landed on, orbiting, or in transit to the planets added by OPM. Anything related to the standard stock planets should be unaffected.

You're right, I messed up the staging. After fixing the staging, I have the same problem as you - the first stage engine won't ignite after SRB separation. However, stage 1 separation and stage 2 ignition now works correctly. As far as the SRBs having insufficient thrust, I'm using BetterSRBs (I failed to mention that).

I'm getting mixed results. It works fine with your GT-Test-2, but when I tried it on one of my saved craft, I got some weird results. I also tried building a new craft and it didn't work. Here's my results: GT-Test-2 - works correctly. Old saved launcher - This craft includes radial SRBs and engine plates with multi-engine configurations on the second and third stages. During launch the SRBs did not separate after burnout (I had to stage them manually). After burnout of the first stage, the stage automatically separated at the engine plate, but the second stage engines did not ignite (I had to ignite them manually). I did not continue the launch long enough to see what would happen with the third stage. Newly built launcher - While much different from the old launcher, the basic design is the same, having radial SRBs and an engine plate decoupler on the second stage. During launch the SRBs separated correctly. After burnout of the first stage, it would not decouple at the engine plate (I had to stage it manually). After separation the second stage engines automatically ignited. (This is the same behavior I typically got with the old Gravity Turn.)

I get the same result. 1 & 3 works, 2 does not. #2 is the exact scenario that I attempted to describe in my bug report.

@linuxgurugamer, I don't know if this has been mentioned before, but I've got a bug to report. Gravity Turn's automatic staging doesn't work when an engine plate decoupler is used. Regular decouplers work fine, but whenever decoupling is to be done using the decoupler built into the engine plates, nothing happens. I always have to decouple manually using the space bar. Once decoupling is complete, the engines will ignite automatically, so that part works. It's not that big of a deal to manually decouple, but it would be nice if it worked automatically as it should. I've experienced this problem ever since engine plates were introduced into the game.

How far is too far? Grannus is about 95 au from the sun at game start. It closes to within 88 au before traveling out to a maximum of 206 au, but it takes 900 years to reach that far. I estimate that with standard propulsion it's possible to reach Grannus in as little as 20 years. Grannus has seven planets, which is more than you want, but I you can always remove some if it's too hard on your system. To remove planets from a planet pack, just write a patch like this: @Kopernicus:AFTER[PlanetPackName] { !Body[PlanetName1] {} !Body[PlanetName2] {} // etc. } Remember that if you delete a planet, also delete its moons. You can write a simple patch like this: @Kopernicus:AFTER[PlanetPackName] { @Body[StarName] { @Orbit { @semiMajorAxis = distance in meters } } }

Are you planning to rescale the system to something larger? Because if not, changing the parts as suggested would make the game ridiculously easy at stock scale. It's already too easy for many people as is. If you plan to play the game at stock scale, I wouldn't recommend changing the parts. On the other hand, if you're planning to play RSS, or rescale the stock solar system (or another planet pack) to lifesize, and you're not interested in Realism Overhaul, then you might try looking into SMURFF. I've never used it myself, but I think it will do what you're asking for. If it's just SRBs that you're interested in, then I suggest BetterSRBs. The fuel mass fractions are still lower than real life in order to stay consistent with KSP's heavier than normal liquid fuel tanks, but generally the stats are much closer to real life SRBs. The trade-off for the better stats is that the SRBs are more expensive.

But there's actually a logic behind 6.4x. It is generally accepted that the scale of stock parts is about 1:1.6 in comparison to real life parts. That is, stock 2.5 m parts compare favorably to real life 4 m parts. It has been common in RSS to multiply all the parts dimensions by 1.6. The logic behind 6.4x is that instead of resizing the parts to fit the universe, the universe is resized to fit the parts. In other words, 2.5 m parts are to 6.4x as 4 m parts are to RSS. It might make sense to go with something like this... 1.585^0 = 1 1.585^1 ≈ 1.6 (probably not needed) 1.585^2 ≈ 2.5 1.585^3 ≈ 4 1.585^4 ≈ 6.4 1.585^5 ≈ 10 1, 2.5, 6.4 and 10 are already commonly used scales, only 4x is new in place of the old 3.2x. ** The 1.585 number comes from, 10^(1/5).

I've never considered that. Of course just having a flat thrust curve doesn't do anything to provide compatibility with stock because other stuff changes too, like thrust and specific impulse. It would probably be feasible to make one of the fuel grain options "stock compatible" that would change everything back to the stock values, but that's not something I'm interested in doing. You are correct, the first number is the fraction of fuel remaining and the second is a thrust multiplier. The third number is the slope in and the forth number is the slope out. For instance, we can see that the slope between the third and fourth keys is, (1-1.2418)/(1-0.61) = -0.62. Here it happens to be a straight line but it need not be. By changing the slopes we can produce curved segments between keys.

UPDATE Version 1.2.4 Changelog Added support for Mk3 Stockalike Expansion. See opening post for download link and instructions.

What Render and Texture quality settings are you using in your game setup? JNSQ was designed to use the maximum settings. Using lower settings can change the terrain so that objects can end up floating or partially buried. If this is the case, then I recommend either using maximum settings or, if that's not practical, changing KSC's elevation. To edit the elevation, find the file JNSQ/JNSQ_Bodies/Kerbin.cfg, scroll to the SpaceCenter at the bottom and change this line to suit: repositionRadiusOffset = 293

@GEPEG_Unconscious, welcome back. I was hoping we'd eventually see more.

I have not seen or heard of anything like that. I have no idea what could be causing it.

If you want to write RR configs for GPP and GEP that overwrites those that are packaged with those planet packs, I'd be OK with that. I would just ask that it all be handled on the RR side so no changes to GPP and GEP are needed. And, of course, if RR is not installed, then the GPP/GEP configs would govern. I would also like you to use templates that are most like the resource distributions currently used (i.e. don't turn them into something they are not already).

It depends on why the mission failed. If it failed because of an improper design or mission plan, then I'd redesign and try again with a new mission. If it failed because I did something silly like time warp past a maneuver node, I'd quickload and do it again. (I figure in real life there would be so many safeguards in place that something like that would never happen.) If it failed due to poor piloting, then it depends on the circumstances. For instance, if I did something like inadvertently hitting the wrong key, like staging when I didn't mean to, I'd probably quickload and redo it. (Again I figure real life safeguards would prevent such an accident from happening.) But if I just flat out crashed the thing because of poor flying, I'd probably accept it as a failure and redo the entire mission. I also do "simulation" flights to check a design, with the intent that I'm going to revert no matter what the outcome.

@coredumpster, I don't know why anything in the patch would cause the problems you're describing. Unfortunately I can't test it because I don't have a Mac. Sounds like you're just better off not using the patch, or consider upgrading to 1.9.1. (edit) I just tested it on my PC in 1.8.1 using the patch and everything seemed to be working fine.

Sorry but I don't know what you are referring to. If the Amos and Prax names are used elsewhere, then it's just a coincidence.

No plans at the moment. I don't know what the future holds.

Top of the page.

No. GEP_JNSQ requires JNSQ to work, and JNSQ and GEP_Primary are incompatible. You can install JNSQ + GEP + GEP_JNSQ, which will add GEP to JNSQ as a rescaled secondary system. But you can't add GEP_Primary to that mix. And if you install GEP + GEP_Primary + GEP_JNSQ, then GEP_JNSQ does nothing. If you want GEP as a rescaled primary system, then I suggest installing GEP + GEP_Primary + Rescale. I don't know what Kerbalism issues you are talking about.

There could be some unintended consequences with changing templates, but hopefully nothing major. One thing I know that happened is when I switched templates I just removed all PSQmods from the new template. It was just much easier and less time consuming to do it that way. One consequence of that is it removes the Randolith from spawning on those bodies. Not that big of a deal but it is something if you like to hunt anomalies. Hopefully there will come a time with future KSP releases that a patch will no longer be needed.

JNSQ Patch Many of you have undoubtedly experienced a terrain bug while playing JNSQ or other planet packs that looks like this: Thanks to @R-T-B, the cause of this has been identified. I've written a patch for JNSQ that should fix it. Just download the following zip file, select the version of KSP that you are currently using, and install the patch as indicated. Download JNSQ Patch Note that this patch is different from the one provided by R-T-B in the preceding post. R-T-B's patch reverts several celestial bodies to using the pre-1.8 terrain shader. My patch changes the templates of those bodies so that the new terrain shader can remain enabled. WARNING... There is evidence suggesting that this patch can adversely affect contracts. For instance, it has been reported that Mun contracts prior to the patch were converted to Moho contracts after installing the v1.8.1 patch. Unfortunately there is no way to change the patch to prevent this. Therefore, it is recommended that you complete, or cancel if you can afford to, all accepted contracts prior to installing the patch. New contracts generated post-patch appear to be OK.

GEP Patch Many of you have undoubtedly experienced a terrain bug while playing GEP or other planet packs that looks like this: Thanks to @R-T-B, the cause of this has been identified. I've written a patch for GEP that should fix it. Just download the following zip file, select the version of KSP that you are currently using, and install the patch as indicated. If playing KSP v1.10+, no patch is required. Download GEP Patch

GPP Patch Many of you have undoubtedly experienced a terrain bug while playing GPP or other planet packs that looks like this: Thanks to @R-T-B, the cause of this has been identified. I've written a patch for GPP that should fix it. Just download the following zip file, select the version of KSP that you are currently using, and install the patch as indicated. If playing KSP v1.10+, no patch is required. Download GPP Patch