OhioBob

If you are using JNSQ, you are using TweakChutes because it's part of JNSQ. I tested TweakChutes thoroughly and had no problems whatsoever with it, but I wasn't using ReStock. If you want to run a test without TweakChutes, just remove the following folder: GameData/JNSQ/JNSQ_Plugins/Sigma/TweakChutes/. If the problem persists, then it's not TweakChutes. There is nothing else in JNSQ that should have any affect on parachutes whatsoever.

Because KSP does that whenever any changes are made to a star's atmosphere. It is unavoidable unless we just don't change the atmosphere, in which case all stars will default to the stock sun atmosphere. If you want to get rid of the artifact and don't mind Ciro having the wrong atmosphere, then delete the atmpsphere{} node from Ciro.cfg.

The instructions revision is for the next version of JNSQ. We were planning to push the new release tonight but it got delayed (hopefully tomorrow). I jumped the gun edited the post about the sunflare before I should have. Sorry about that.

@linuxgurugamer, SmartParts is now a recommended mod for BetterSRBs.

UPDATE Version 1.0.9 Changes made to help compatibility with other mods (e.g. ReStock). See opening post for download link and instructions.

The only thing that I think could be a little messed up are the science definitions (the descriptions you get when you run an experiment). They may not be entirely applicable to the revised planets and biomes. If you can overlook that potential flaw, I think all the parts should function just fine.

I don't think so. Having atmospheres of different densities and heights can certainly alter delta-v, but any differences here are well within the margin or error of a delta-v map. Delta-v maps are just a ballpark estimates.

Sorry for the delay in responding. It is our recommendation that both the antenna range and DSN modifiers be set to 4x. Our previous posts mentioned only the antenna, but that's an oversight. Setting only the antenna range modifier to 4x will double the combined antenna/DSN range. That is only good enough to reach Jool. Setting both the antenna range and DSN modifiers to 4x will quadruple the combined antenna/DSN range, which is what is needed to reach Eeloo and Hamek.

Not unless the planet was really really close to the star. Planet orbits are typically much large than the radii of stars.

Other planet packs will load. That's not what I meant when I said they wouldn't work. I just meant that the packs would be horribly mismatched. If you don't mind mixing 1/4 scale and 1/10 scale together, then there's nothing stopping you.

And we've included orbits like that elsewhere. I don't want to do it with Minmus.

You can always make your own config to overwrite whatever we do to set it up as you want it. If I wanted to make the system realistic and same for everybody, I'd delete Minmus altogether. But I don't see that as an option. I'm reasonable confident that Principia users are a small minority. Making the system work for them is a courtesy. I'm not going to do something that affects everybody else just so Principia works for a few.

Since JNSQ is natively 1/4 real scale, it will not work with any other planets packs unless they too are designed around the same scale. And to my knowledge, none are (at least not yet). So JNSQ is designed to be used by itself. It is possible that other planet packs can be resized to fit JNSQ (or JNSQ resized to fit other planet packs) using Sigma Dimensions. However, it cannot be done in the normal way using the global resize and rescale factors. You would have to use planet specific changes to target only the celestial bodies that you want to resize. This is outside the scope of what we plan to do with JNSQ, so will we provide no technical support for it. Feel free to experiment, but you're on you own. I did not experiment with a high inclination orbit, but that is not something I would be interested in even if it worked. Minmus' orbit can also be stabilized by making it retrograde, but that too is something I wasn't interested in. High inclinations and retrograde orbits just seem too contrived to me. My preferred method is the one that's we're using.

Yes, the situation has been resolved. I posted a patch for those who want to implement the change now rather than wait for the next release: With Principia installed and Minmus in its current orbit, Minmus is ripped from its orbit by the Sun's gravitation. Moving it farther out will only make the situation worse. And I don't think changing the SOI will have any effect on it because, as I understand it, Principia doesn't care about SOI, as it models gravitation in a more complex and realistic way. I found that moving Minmus in (from about 181 Mm to 147 Mm) fixes the problem with the Sun wanting to pull it from its orbit, but now Mun's gravitation perturbs Minmus into a very chaotic orbit. Eventually Minmus gets ejected out of the system. The answer to stabilizing Minmus' orbit for Principia users is to move Minmus' orbit inside that of Mun. But as Galileo explained, that makes to order of contracts feel a bit out of sequence. So we've decided to move Minmus inside Mun only if Principia is installed. For other players, Minmus stays outside Mun, though we are moving it to the smaller 147 Mm orbit.

I agree. I'm not sure why I didn't increase the cost the first time. I've changed it so cost, mass and thrust all increase by the same factor.

Rescale is already set up to work with Kronometer. All you have to do is download and install it. It will make the calendar day and year equal to the rotation and orbital periods of the home world.

Some of us has been experiencing severe performance issues with Kopernicus/JNSQ in version 1.7.1. I don't recommend 1.7.1 until we can identify and fix the problem. If you must use 1.7.1 and are experiencing performance issues, then I recommend you turn off terrain scatters in your game's graphic settings.

Ice geysers is a possibility (we actually did that already in GPP). Eve isn't hot enough for molten rock, unless it's volcanic. (I actually think the lava sea idea is starting to get old.) And how much of JNSQ have you explored? Maybe there is fun stuff out there to find that you just haven't found yet? And don't forget, JNSQ is only at version 0.4. It's not finished yet. (edit) Regarding Nara, its size and orbit is intended to resemble "Planet 9", though with a smaller semimajor axis so it does take so bloody long to get there. Appearance-wise, you'd have to ask Galileo. I don't know if he had any particular inspiration when creating it.

One of the primary goals of JNSQ was to be more scientifically accurate. It is intended for players in seek of something that looks and feels more realistic than the stock game, but without scaling all the way up to RSS. If the moons look like those in RSS, then we've come close to achieving our goal of making something that resembles real life. While some of the "difficulty points" of stock have been removed, there are other things that have been made more difficult. We don't want JNSQ to be a carbon copy of stock. Been there, done that. If what I've described doesn't float your boat, then JNSQ may not be the mod for you.

Sigma Dimensions has been updated... https://github.com/Sigma88/Sigma-Dimensions/releases/tag/v.0.10.3 I can confirm that the following works, though I make no guarantees that it's bug free: KSP 1.7.1 Kopernicus 1.7.1-4 Sigma Dimensions 0.10.3 Rescale 1.0.2.8

FYI, JNSQ does make a couple part changes. The LV-TX87 and LV-T91 engines (Making History DLC) are suppose to be analogs for the real life Aerojet LR-87 and LR-91 engines. These real life engines powered the Titan II ICBM, from which the man-rated Gemini-Titan was derived. As such, we believe the LV-TX87 and LV-T91should be able to power a rocket capable of launching a Mk2 command pod and service module. While these engines can accomplish this task at stock scale, we found them to be a bit unpowered at 1/4 real scale. We therefore increased their thrust and mass to compensate. The LV-TX87 has had its thrust and mass increased 25% to 500 kN and 2.5 t, and the LV-T91 has been increased 20% to 150 kN and 1.2 t. These are the only part changes that JNSQ makes. If you decide you don't want the part changes, then delete the file, GameData/JNSQ/JNSQ_Configs/partMods.cfg.

Until now it hasn't needed an update in the last five months. That being said, I don't know what @Sigma88's plans are going forward. While I don't think he has abandoned his mods, he does seem to go on an occasional hiatus. We're just going to have to wait and see what happens. I think it's too soon to start talking about somebody else picking it up.

Probably not. Rescale requires Sigma Dimensions. The new Kopernicus is suppose to break plugins that use Kopernicus. So Sigma Dimensions is likely broken.

Note also that antenna and DSN range can be extended via sliders in the game difficulty settings. For JNSQ we recommend antenna range and DSN modifiers of 4x. This will allow the best stock antennas to maintain a connection with Kerbin to just past the orbits of Eeloo and Hamek. Although the JX2 is not an absolute necessity in that case, it will greatly increase the signal strength. Extending range all the way to the planet Nara, however, requires both the 4x modifiers and the JX2 antenna (or a system of relays). Of course you can use any combination of parts or antenna range modifiers that you want. The best parts and settings are whatever sounds most fun to you.

I replied to your post earlier, but I didn't specifically address the second part of your question. Let's say we simply scaled up Tylo to 2.7x without making any of our other changes. Would that make Tylo harder to land on? The answer is yes and no. Increasing Tylo's size and mass will increase approach and/or orbital velocities, thus requiring more breaking delta-v to execute a landing. The difficulty is in getting that extra delta-v capability (more fuel, etc.) to Tylo in the first place. But execution-wise, it's really not that much different. Just a longer burn is all, but that's not an especially difficult problem to overcome. Breaking from orbit just sets you up for the final descent and landing. During the final descent phase, where you guide the vessel to a soft landing, all that really matters is the surface gravity. The overall size of the body at that point is mostly irrelevant. Stock Tylo and 2.7x Tylo both have the same surface gravity (0.8 g), so controlling the lander over that last short distance is going to play the same in either case. And, to me, it's the final phase that's the real challenge with landing on Tylo. So I would say it's probably not that much more difficult to land on Tylo at larger scales than it is at stock size.