OhioBob

Supposedly, yes. There's a config for it. I'm not familiar with RemoteTech, so I don't know. Hopefully somebody with some RemoteTech experience can answer.

@OrbitalManeuvers, I just ran a test and everything worked as expected for me. No problems. What version of JNSQ/TweakChutes are you using? JNSQ v0.10.1 came bundled with TweakChutes v0.3.0. JNSQ v0.10.2 upgrades to TweakChutes v0.3.1. If you're using the older version, perhaps that's the problem. If so, try replacing the TweakChutes in the JNSQ_Plugins folder with this one: Release Sigma TweakChutes v0.3.1 · Sigma88/Sigma-TweakChutes (github.com)

That's normal in the stock game. Parachutes will full-deploy when reaching the height setting regardless of whether the minimum pressure condition has been satisfied or not. This is one of the things that TweakChutes was specifically designed to correct. I'm going to run some tests now to see what happens on my end.

@OrbitalManeuvers, your problem doesn't really sound like it's JNSQ or TweakChutes related, but I won't rule it out just yet. It might be interesting to remove TweakChutes to see what happens. To do so, just temporarily remove the folder JNSQ_Plugins. I haven't had a chance to do any testing on my end yet. That does make sense if you had the altimeter set to height above terrain. Drogues should semi-deploy at an altitude of about 7000m above sea level. But if you were flying over terrain with an elevation of about 2500m, then they would semi-deploy at 4500m above the ground. And since you are already inside the 5000m height for full deployment, they would immediately inflate.

I've never seen that before. If the pressure is high enough for the parachutes to deploy, they should inflate when they reach the height setting. I know of nothing in JNSQ that would stop that from happening. JNSQ does use a plugin called Sigma TweakChutes that changes parachute behavior, but it shouldn't affect parachutes in the way you describe. In stock KSP, parachutes will immediately deploy and inflate when reaching the height above terrain that you have set in the parachute slider even if the minimum deployment pressure has not yet been reached. TweakChutes stops this from happening. With TweakChutes a parachute will never deploy until the minimum pressure has been reach, and it will not inflate until both the minimum pressure and the altitude has been reached. This is why main parachutes won't deploy on Duna because the minimum pressure is never reached. Drogue parachutes, however, should deploy once descending below an altitude of 7068 meters where the air pressure is equal to 0.02 atm (assuming you have them set to deploy at that pressure). Once deployed, there should be nothing stopping them from inflating when you've reached the set altitude above terrain. I suppose it's possible that the latest version of KSP has produced a bug in TweakChutes that could be causing this. I doubt it, however, because in the past TweakChutes has been pretty immune to KSP updates. I should check it to be certain.

The minimum pressure for the parachutes is in units of atmospheres, while the pressure displayed by the PressMat Barometer is in units of kilopascals. 1 atmosphere equals 101.325 kPa, so to convert kPa to atmospheres, divide kPa by 101.325. So in the particular screenshot provided, the pressure displayed in the PressMat is, 3.3237 / 101.325 = 0.0328 atm. The minimum pressure to deploy drogue parachutes is 0.02 atm, so since 0.0328 atm is greater than this, the drogues have deployed. But the minimum pressure to deploy main parachutes of 0.04 atm has not been reached, therefore the main chutes have not deployed. In JNSQ the maximum surface pressure on Duna is 0.04 atm, therefore main parachutes should never deploy. (In practice they might deploy a second or so before impact, but too late to really do anything.) This is by design. We don't want main parachutes to work on Duna to make landing on Duna more Mars-like. That is, one can use drogues to slow and stabilized the vehicle, but propulsion will likely be needed to slow the vehicle enough for a soft touchdown.

UPDATE Version 1.2.6 Changelog: Added DeployedScience config. EVE fixes to improve compatibility with GPP. This mod is not compatible with Scatterer v0.0825b, please use v0.0772. DOWNLOAD

UPDATE Version 1.6.8.0 Changelog: Added DeployedScience config. EVE fixes to improve compatibility with JNSQ. This mod is not compatible with Scatterer v0.0825b, please use v0.0772. DOWNLOAD

UPDATE Version 0.10.2 Changelog: Added DeployedScience config. Updated TweakChutes to v0.3.1. This mod is not compatible with Scatterer v0.0825b, please use v0.0772. DOWNLOAD

This issue has been reported numerous times but I have yet been unable to reproduce the problem. It has been reported that it only happens in career mode but I can't confirm that. Until I get a bug report with clear and detailed steps on how to reproduce the problem, I won't be able to find the cause or fix it.

I have no idea what I'm looking at in your screenshot. Are you using some sort of contract mod? If so, I have no familiarity with that. I've never used one and don't how they work or what they are supposed to do.

@Gordon Fecyk, if you think these couple of changes fixes everything, then I really don't need to see the video. When you talked about "clouds" breaking, then the cloud configurations are all I bothered to look at. I forgot all about the atmospheres and never thought to even look at that. We have so many different ways to install this stuff that it's hard to remember to verify every possible combination. You apparently just happen to hit on a combination that slipped through the cracks. I'm glad you figured it out. Thanks for the help. Although the renaming thing you talked about isn't strictly needed, I made the change anyway. It's just good practice I think to do it as you suggested. I'll probably release a quick update within the next couple of days.

Are you using latest scatterer, v0.0825b I think it is? If so, don't. JNSQ is not updated for it. Use scatterer v0.0772. If you aren't using the latest scatterer, then I don't know. I can't know what you are doing wrong if I don't know what you are doing.

You're correct about that. Up until the last GEP release, Nodens used a texture named kerbin1.dds. But v1.2.5 upgraded Nodens to a higher resolution cloud texture, and in doing so I changed the name to Nodens_clouds.dds. In Clouds.cfg I changed it in one place {!GPP] but not in the other [GPP]. I'll have to fix that. You're right about that too. The EVE clouds have a [!JNSQ] condition, but the atmospheres do not. Those atmospheres only execute if EVE is installed and scatterer is not, so they're not seen very often. I probably failed to test them in the particular scenario that you're using. It likely causes a problem if and only if the following are used: JNSQ + GPP_Secondary + EVE and no scatterer. When using scatterer, do make certain to include the appropriate Rescale mods. JNSQ breaks scatterer for other planet packs. The fix for this is included in the Rescale mods.

Maybe eventually but nothing near term. I'm not really motivated at the moment to figure out what changes are necessary.

Didymos' sphere-of-influence was artificially inflated to make getting an interplanetary intercept with it using maneuver nodes comparable to other celestial bodies in the game. Didymos' mathematically computed SOI is only 5.5 km, which would be unplayable. It would be virtually impossible to get an intercept with something that small, leading to player frustration and complaints. Didymos was given an SOI similar to that of Dres because we felt that would make the difficultly not any greater than what players are already accustomed to in the stock game.

No rush, but I would like to get to the bottom of this. Whenever I release an update, one of the things I test most rigorously is EVE, because that's one of the things that is most easily messed up. I don't understand why clouds are working fine for me and not for you. Doesn't make any sense. Just to be sure we're on the same page, here's what I'm using: EVE-Redux, v1.11.5.1 GPP, v1.6.7.0 GPP_Secondary GPP_Rescale, 2.5x JNSQ, v0.10.1 scatterer, v0.0772 ModuleManager, v4.2.1 I also tested it using EVE v1.8.0.2, and without GPP_Rescale, and without scatterer. In all cases I found no cloud related problems. I'm also not seeing anything out of place in the ModuleManager cache - i.e. the GPP configs for the stock bodies are not executing, as should be.

@Gordon Fecyk, you're going to have to tell me exactly what you are doing to cause this so I can reproduce it. Because I tested JNSQ with GPP_Secondary after reading your initial post about this and had no issues (i.e. all clouds are working as they should). So clearly you must be doing something differently then I.

I haven't noticed clouds breaking. None of my tests have ever revealed a problem. Which clouds break specifically and with what installed? GPP isn't suppose to replace clouds on the JNSQ stock worlds. GPP adds clouds to the stock worlds when installed secondary to the stock solar system, but this is disable when JNSQ is installed, i.e. NEEDS[!JNSQ]. I can see how the naming thing can be an issue -- could end up with two EVE objects with the same name if not careful. I think we got lucky, however, because GPP uses "-" in its names while JNSQ uses "_", so they really aren't the same. I don't think your suggestion really does anything in this particular case, nonetheless, it's a wise precaution and I plan to implemented the change.

Contacts require completion by a certain deadline. So just be aware of that and not let the time expire without completion or you'll take a hit in lost funds and reputation.

I've tried this in career mode and I still can't get a crash. I've flown to Iota and Ceti twice each and haven't experienced any problems.

Thankyou. Will include a version of this in the next update.

My efforts so far have been unable to reproduce this problem.

It hasn't been tested, so I can't guarantee that it will work. You could run into problems. It shouldn't be game breaking, however.

Then it is most likely an installation error. When installing Kopernicus, did you also install ModularFlightIntegrator and ModuleManager? And as Pehvbot said, make sure you have all the required pieces of the planet pack installed, and installed correctly. If any folder is out of place, it won't work. A screenshot of your GameData folder might be helpful.