OhioBob

I don't want you to do anything that you don't like. I was just hoping there'd be an easy solution. Thanks for looking into it.

@blowfish, is it possible to change the "title" of a part (the display name) when selecting a variant? I'm working on switching my Eve Optimized Engines mod over to using B9 Part Switch. The plan is to have the standard engine and the Eve optimized version as switchable variants. I'd like the Eve variant to have a different model number and name than the standard. I've got everything working but for one issue. When I mouse over the part, it always shows the standard stock title. Is there presently a way to make it show different titles for different variants? And if not, is this a feature that could be added? Thanks.

OK, I see how you did that with ExpVapour. I notice you already include support for several planet packs. I presume you'll add JNSQ? If not, we can always do it on our side. For your information, here are the planets that I envision having methane in their atmospheres: GPP - Otho (~1%), Gauss, (~2%), Catullus (~2%), Tarsiss (~8%) JNSQ - Lindor (1%), Huygen (4% average, ~6% near surface) And Eve has an unidentified mix of heavy hydrocarbons (similar to kerosene): JNSQ - Eve (about 0% to 2% in troposphere) These are the ones having hydrogen atmospheres: GPP - Otho (~87%), Gauss (~83%), Nero (~91%), Catullus (~73%) JNSQ - Jool (90%), Lindor (86%), Nara (80%) For JNSQ the abundances are stated in the planet configs. For GPP I'm estimating based on mean molar mass. Of course you can assume higher hydrocarbon abundances if necessary to make the engines work. These are just the percentages I used when I did the atmospheres.

@Gordon Fecyk, if the two modes are different enough that it's unrealistic to engineer both into a single part, then I say make them separate parts. I personally wouldn't expect that I could fly the same craft in two entirely different atmospheres like Titan and Saturn. But that's just my two cents, for what it's worth. Have you given any thought to how you'd place a constraint on the engine so that it works only in hydrogen atmospheres?

The mod has nothing to recompile, it's just config files. But it does bundle outdated versions of its dependencies. From Quarter-RSS-v10.zip, just install the QuarterRSS folder and not the rest of it. Then go download and install separately the 1.8.1 version of Kopernicus.

Everything has been computed based on the size and shape of the booster. The Shrimp is long and narrow in comparison to the Flea, therefore it has a longer channel running through the center of the fuel grain with more exposed surface area. Therefore it burns its fuel more rapidly with a greater thrust. But because the Shrimp is narrower, it doesn't burn as long because there is less fuel thickness to burn through. The upgraded Flea actually delivers greater impulse (thrust * time) than the Shrimp, but it does so in a different way. The Shrimp delivers greater thrust for a shorter time, and the Flea delivers lesser thrust for a longer time. This gives you options so you can pick the one that best suits your needs.

@Gordon Fecyk, have you ever considering adding a hydrogen breathing variant? It would be the same basic concept as your explodium breathing engines, but would work in hydrogen atmospheres. Obviously gas giants would be one place they'd work, but I got thinking about this specifically for the planet Nara in JNSQ. Nara has a hydrogen-helium atmosphere with a surface pressure of 40 atm. At that pressure obviously none of stock rocket engines will work (not even Eve Optimized Engines). So a jet engine that takes in hydrogen from the atmosphere and burns it with an onboard oxidizer might be the perfect solution to allow launches from Nara's surface.

Sorry, didn't mean to make more work for you. lol By the way, I'm enjoying your video series. good stuff. FYI, the fix to the sliders is only half of what TweakChutes does. In stock KSP, the minimum pressure setting applies only to semi deployment. A parachute will full deploy when reaching the altitude setting regardless of the pressure. This is again something we think is flawed (if the pressure is too low for semi-deployment, it makes no sense that it should full deploy). TweakChutes assures that both the pressure and altitude conditions are satisfied before full deployment can happen.

TweakChutes is designed specifically to stop you from doing what you are doing by fixing what we believe to be a bug in stock KSP. The minAirPressureToOpen for main parachutes is set in the part configs to 0.04 atm. When designing a vessel in the VAB/SPH, it's impossible to set the parachute deployment pressure below the minimum. But after a vessel is sent to the launchpad/runway, it's possible to right-click on a parachute and turn the slider down all the way to 0.01. We consider this a bug/exploit as it seems clear a player shouldn't be able to set a parachute to open at a pressure less than the intended minimum. TweakChutes fixes this so the slider can never go below the minimum specified in the part configs. We designed Duna the way it is in JNSQ and bundled TweakChutes because we don't want people using main parachutes on Duna. Our intent is to make it more Mars-like and increase the difficulty of landing there. Drogue parachutes can be used to slow a vessel down, by probably not enough for a soft landing. We want players to have to use propulsion to provide the last bit of braking prior to touchdown (or use their ingenuity to figure out some other landing method). By removing TweakChutes you are circumventing an obstacle designed into JNSQ to make it more challenging.

Thanks for the mention, but only Eve Optimized Engines is by me. Explodium Breathing Engines is by @Gordon Fecyk.

I think it likely that everybody is going to have different ideas regarding what information to put on a quick reference guide. Our pdf includes most all the information that players could be interested in. But if players want to trim that information down into a more condense version, I think it is probably best that each individual player do it for themselves. That way each player can have the specific information that's of greatest interest to he or she. If we were to do it, we'd likely get requests asking that this be added, or that be added, or that something be removed. Nothing we would do could possibly satisfy everyone.

Clouds not showing up on the menu screen is not uncommon. Are you getting clouds in game? If so, then don't worried about the menu screen, it doesn't matter.

I think you explained it correctly. Here was my explanation: Since we wanted to make landings on Duna more Mars-like, we reduced its maximum atmospheric pressure to 0.04 atm. That just happens to be the minimum deployment pressure for main parachutes. So that means nowhere on Duna is the atmospheric pressure high enough for main parachutes to deploy. The minimum pressure for drogue parachute deployment is 0.02 atm, which occurs at an altitude of about 7 km on Duna. Also note our warning in the open post: We expect players of JNSQ to drop all their preconceptions, do their due diligence, and assume nothing. JNSQ is an entirely new planet pack, and it is best to approach these bodies like you've never been there before.

It's not a problem, it's a feature of JNSQ. Main parachutes aren't suppose to deploy, Duna's air is too thin. Drogue chutes work though.

Although you did it backwards from what we suggest, you are right in that the results would still match up to our diagram. The distance over which antenna/DSN can communicate is proportional to square root of the product of the Range/DSN modifiers. The way that we suggest doing it, both Range and DSN modifiers are 4. But the way you did it, DSN is 1 and antenna are 16 because they get multiplied by 4 twice. So antenna to DSN range comes out the same, SQRT(4*4) = SQRT (1*16). That's correct. Although antenna to DSN range was correct, antenna to antenna range got increased by SQRT(16*16) = 16, which is 4 times what we recommend. You were lucky then, because I had all sorts of science transmission problems when I played. I typically didn't have too much problem when near Kerbin, but the problem seemed to rear its ugly head more frequently when the signal got weaker. Also moving out of signal range and then back in again almost always resulted in the inability to transmit science. (Squad still hasn't acknowledged my bug report on the issue.) Changing mid-game is no problem, but it probably requires a game restart for the new settings to take effect. It is also important that the Range modifier be exactly 1. The slider can be a bit temperamental at times. If you can't set it exactly to 1, you may have to edit the persistent.sfs file of your saved game. Just search for rangeModifier and change the value.

By different we me that it is an entirely new planet. All the celestial bodies in JNSQ are completely redone. They retain their original names, and their relative positions as sizes are mostly the same, but otherwise they are all new. There are also new bodies added. Here's a photo album with some nice screenshots of each planet and moon: https://imgur.com/a/n9XBUdW

Yes, those loading screens are from GPP. It's not done by a mod. It's digital artwork created by Galileo from some screenshots. I'm not sure what software he used to create it.

In addition to what Galileo said, some of the settings are placeholders. Once we have the chance to inspect things more closely, we might decide to change things. If you are in the middle of a save, there's no telling what affect changing something like the landscape multiplier might have on landers, bases, etc.

No. I don't remember exactly why it doesn't work for pre-1.5 versions, but it had something to do with Squad deprecating old parts and replacing them with new versions. By the way, did you really need to quote the entire opening post? Can you edit your post to delete the unnecessary wall of text?

UPDATE Version 1.2.0 Changelog Added selectable grain geometry using B9 Part Switch. Tweaked default thrust curve. Revived custom texture for BACC Mk2 "Ram" SRB. See opening post for download link and instructions.

Because JNSQ is not made to work with OPM. They are at two entirely different scales and will not fit together (they overlap). Also JNSQ has some outer planets of its own.

@Jiraiyah, from the OP...

We're planning to release a 4x config for Sigma Dimensions that will make JNSQ real scale. So far we've only briefly experimented with it, and very little debugging has been done. I'll share the config with you, but bear in mind that this is unofficial, and therefore unsupported. Use at your own risk.

Days are Kerbin days of exactly 12 hours. Years are Kerbin years of exactly 365 12-hour days.

You can do it that way, but I'd advise against stretching it by a factor any greater than 1.25. Using a factor of 1.25 will give Kerbin a height-pressure gradient exactly the same as the real life Earth. Stretching it more than that means that at altitude the atmospheric pressure is higher than should be. If you want to go higher than the 1.25 factor provides, I recommend extending the curves, not stretching them. I suggested using Sigma Dimensions only because it has built into it all the tools needed to stretch/extend the atmosphere. If you want to both stretch (by 25%) and extend (to 100 km) the atmosphere, I recommend this: