OhioBob

I don't plan to move the existing belt, but I might add a new one. Between Nodens and Sirona was one of the places I was thinking about adding a new planet. Maybe I can make it a small ore/metal rich dwarf planet within an asteroid belt (as you suggest).

@darwinpatrick, since you're getting ore in some places, it seems the system is working at least. Overall I went pretty skimpy on the resource allocation in GEP. Maybe too much so. It's something I figured might need fine tuning to get it right. But I've never received any feedback on it one way or the other. I don't really play the game that much anymore, and when I do I rarely so anything with resources. So if tweaking is needed I wouldn't know about it unless somebody tells me.

That just sounds like bad luck, unless something broke since I set it up originally. I haven't check it in a very long time so I honestly don't know if it's working or not. GEP has custom resource configs for all the bodies to try to make things more realistic than just random chance. Ore should be more likely and abundant on inner rocky bodies than on icy outer bodies. On Airmed, each biome (except for poles) should have a 60% chance of ore being present in a concentration of somewhere between 1% and 4%. To have none is not impossible, but it's very unlikely considering it has 8 biomes that could potentially have ore. I don't know how hard mode effects those percentages. If significantly reduced, that could explain your bad luck.

The only bodies whose surfaces are completely unchanged are Nodens and Airmed. The others I thought looked better by scattering some fresh craters around their surfaces. Unless you have something landed on one of the bodies that got new craters, your save should be fine. And even if you do have something landed there, it may still be OK. There's just a possibility that something could be damaged by a crater being in a location where previously there wasn't one.

UPDATE Version 1.0.2 Changelog Added procedural craters to eight celestial bodies. Exported updated color and normal maps. Completely reworked Cernunnos' color map. Reworked Taranis' ocean (coastline and color). Revised Taranis' biome map (shores). Lowered Belisama's contrast and saturation. Added subtle coloration to Damona. Revised ScaledVersion and PQS fadeStart/End altitudes. Disabled useOnDemandBiomes. Updated CelestialBodies.pdf. Please be advised that since procedural craters have been added to most bodies, this update has the potential to cause problems with existing saves. Any landed vessels, bases, or surface infrastructure could be damaged or destroyed by changes in the surrounding terrain. See opening post for download link and instructions.

I hadn't considered adding anymore rings but I won't rule it out. Cernunnos is the planet that has changed the most in the next update. It has a completely new color map. I've really struggled making it a color that I like. I changed it once already and now again. I think I'm finally finished messing with it.

@darwinpatrick, yes, I'm still maintaining this mod. In fact, I recently made some upgrades but haven't released them yet. I probably should go ahead and do that. I've also been considering adding a few more planets, but that's not certain. I'd be delighted in seeing your mission reports. I had a lot of fun in playing GEP_Primary as well. Because the planets orbit a red dwarf, the game has a very different feel to it than stock KSP. It was a nice change of pace and different from any other planet pack I've played. Taranis is designed to be one of the most difficult challenges you'll find anywhere. I've flow by it and landed a probe on it, but that's as far as I went. I've never landed Kerbals on it nor returned from it. My flyby through Taranis' SOI took all of about 40 seconds! And, as I recall, my landing required a total mission delta-v of something like 34 km/s. The velocities are just really extreme there. Look for a possible update in the next day or so. There's just one more thing I know of that I need to fix.

No. KittopiaTech is a tool for planet pack developers. There's no reason for the end user to have it installed. In fact, it's best not to because it can actually cause some problems.

Yep, I also did a launch from stock Eve for 7500 m/s. And you're correct, that was vacuum Δv. The 7000 m/s value for JNSQ is also vacuum. I made a mistake when I typed sea level (I've since corrected it).

Because that's what it took when I did it. Of course that's not from sea level with stock engines, which is pretty much undoable at 10 atm pressure. I tested two scenarios: (1) taking off from 2 km (Eve's mean surface elevation) using stock engines, and (2) taking off from sea level using Eve Optimized Engines. In both cases, after some practice optimizing the trajectory, I got to orbit for a little less than 7000 m/s (vacuum delta-v).

Same here. Stock scale is just too bloody easy. JNSQ really hits the sweet spot for me as far as scale goes (about 2.7x stock, but technically 1/4 real scale). It ratchets up the difficulty but is still quite doable with unmodified stock parts (no SMURFF required).

We got some special help from the Koperniucs dev who wrote a custom plugin for it.

I don't know if it would help you or not, but for my BetterSRBs mod I did a complete rebalancing of all SRBs, which you might be able to use for inspiration. I got more complex with it than you seem to be interested in, so I'll spare you all the unnecessary detail. But the basis of my thrust calculations really came down to burn time, with burn time being a function of SRB diameter: Diameter Burn time 0.625 m 18 s 1.250 m 36 s 1.875 m 54 s 2.500 m 72 s And if we know the burn time, everything else follows easily. For instance, the Kickback contains 19.5 t of propellant with a vacuum ISP of 220 s. Therefore the average vacuum thrust is, 19.5 / 36 * 220 * 9.80665 = 1169 kN If this were done for all the large SRBs, we'd have: SRB name Old thrust New thrust TWR % change Thumper 300 kN 352 kN 4.69 +17% Kickback 670 kN 1169 kN 4.97 +74% Pollux 1300 kN 1777 kN 3.52 +37% Thoroughbred 1700 kN 1880 kN 2.74 +11% Clydesdale 3300 kN 3937 kN 2.79 +19% If that is still too low for the 2.5-m SRBs, you can always use a shorter burn time, which can be justified by assuming changes to propellant grain and formula. (From the above numbers it's easy to see just how out underpowered the Kickback really is.) (edit) Sorry if this is going too far off topic. I'll stop now.

I think one of the biggest problems is that the Kickback's thrust is way too low. (About 1200 kN seems more reasonable to me given its size and ISP.) If the larger SRBs were then sized correctly in proportion to a more powerful Kickback, they too would have a higher TWR. The TWR still wouldn't be great, but it would be better and more useful. When I did my SRB mod I didn't even bother with 2.5-m SRBs just because of the low TWR issue. I didn't think they were that useful, so I stopped at 1.875-m.

In fairness to Squad, the new larger SRBs should have lower TWR than the Kickback. Though I agree that the Kickback's TWR (and the Thumper's) is lower than it probably should be. SRBs can use different fuel grain geometries and propellant formulations to alter how fast they burn, and hence how much thrust they produce. But if the burn rate remain unchanged, then thrust becomes mainly just a function of the area of the exposed burn surface. Obviously as a SRB get longer, the burn surface increases proportional to length. And as a SRB gets wider, the size of the central channel gets larger. As long as the basic geometry of the grain is not altered, the area of the burn surface will increase proportional to the diameter. So the end result of this is that thrust is proportional to length*diameter. However, as a SRB gets wider, the cross-sectional area of the booster increases proportional to the diameter squared. This means that the mass of a SRB is proportional to length*diameter^2. And since TWR is thrust divided by weight, we see from these relationships that TWR is proportional to 1/diameter. So all other things being equal, a wider SRB means lower TWR. Of course, as I said, there are other things that can be done, such as increasing burn rate, to increase thrust and TWR. But generally speaking, I don't think the performance of the new SRBs is really out of line in comparison to the other SRBs. By some measures the performance may be abysmal, but that doesn't make it unrealistic. It's just that, contrary to what some may believe, making a SRB wider is not the answer if you want a high TWR.

I don't think they are really that bad in comparison to the others. The bigger SRBs have lower thrust-to-weight than the smaller ones, but that's what happens in real life. Generally speaking, as a SRB gets bigger, the thrust goes up proportional to the length*diameter, but mass goes up proportional to length*diameter^2. So as diameter gets larger, TWR goes down. If you want really high TWR, a fatter SRB is not the answer. One of the things my BetterSRBs mod does is to make sure all SRBs are realistically balanced in proportion to one another. Dry mass and fuel load is computed based on the physical dimensions of the SRB. Thrust is also computed based on physical dimensions, along with a presumed fuel grain geometry and burn rate. Most SRBs have higher TWR than the unmodded parts, but some actually have less.

No planet packs work on 1.8 because they all require Kopernicus, and Kopernicus hasn't updated yet. We plan to update to 1.8 once Kopernicus is updated, but we don't know how long it will take. We also know that 1.8.1 is coming, so it really doesn't make sense to do anything at this point. We'd like to get the bugs worked out of KSP itself before we consider updating JNSQ.

(1) SVE doesn't work, and (2) it's not needed as JNSQ includes its own visual enhancements. We currently have no plans to implement that.

70 km is still well within Kerbin's atmosphere in JNSQ. You need to get above 85 km. And no, 5000 m/s circularization is certainly not how it's suppose to be. In the JNSQ directory is a file titled CelestialBodies.pdf that contains all the new data for the reinvented JNSQ bodies, such as atmosphere height. There is also a delta-v map, JNSQ_DV-01.png.

Dynamic pressure is proportional to velocity squared, while heating rate is proportional to velocity cubed. So as speed goes up, heating increases much more than dynamic pressure. That is why it is so much easier for a craft traveling at high velocity to overheat and burn up before it has sufficiently slowed down. Reentry velocities in JNSQ are about 63% higher than they are at stock scale, thus making heat a much bigger thing to deal with.

While I was watching, low orbit.

JNSQ + Deadly Reentry is generally a bad idea. I haven't done it, but @Rocketology streamed it. It was almost impossible to keep his stuff from burning up.

Please be advised that I have revised my VoronoiCraters tutorial. After completing a more extensive study of the effect of CraterCurve and voronoiFrequency on crater size and quantity, I discovered that my original tutorial included a bad assumption. I have corrected this by deriving new equations. The section of the tutorial titled Crater Size and Quantity has been mostly rewritten, while the rest is largely unchanged.

UPDATE Version 1.1.0 Changelog Provide support for SRBs added in KSP 1.8 and MH 1.8. Changed required technology for mod-added SRBs. Changed cost of Mk4 nosecone. Reduced Kickback gimbal range. See opening post for download link and instructions. Although the most recent KSP update has added a 1.875-m SRB and nosecone, you get these parts only with the Making History DLC. BettersSRBs has, therefore, retained its 1.875-m SRBs and accessories, which you get with or without the DLC. The added SRBs also nicely complement the "Pollux", providing a good range of sizes with no duplication. Known issue - Although part upgrades are correctly applied, the Tech Tree no longer displays the new stats for the upgraded parts.

Using "OnDemand" means that a body's textures load only when you are in range of that body. "UseOnDemandBiomes" is used specifically for the biome maps. When set to false, the biomes maps are loaded into RAM at game startup. This increases the load time at startup and uses more RAM, but the maps are always available for instance access when needed. When set to true, the maps are loaded into RAM only when demanded. For OnDemand to work, the maps should be in .dds format as these load very quickly. It has been pretty common practice for most planet packs to have biome maps in .png format, which take longer to load when demanded. It is this extra load time that can cause a delay when switching map modes. By default, Kopernicus uses UseOnDemandBiomes = true. Changing that to false eliminates the lag time because the maps are already loaded.