OhioBob

No idea. None of the JNSQ team uses Kerbalism, so none of us follow its development. If we get bug reports, then we'll probably have to look into it. Sorry I can't be more specific, but I just don't know.

It looks like MechJeb is still using the coodinates of the stock KSC. (The distance between our location and the stock location is 467 km.) I'm guessing we have a syntax error in our config. We'll look into it.

@New Horizons, I just launched a big 375-tonne Mun rocket. Its to low Kerbin orbit payload fraction was 0.11, but that was leaving a little bit of unused fuel in the tanks. I estimate that if squeezed every last ounce of potential out of it, I might have been able to get the payload fraction up to around 0.12.

I just tested it in my career game and I can take surface samples with no problem. I'm not using any mods that would normally be expected to interfere with something like that.

This has been reported elsewhere. Not quite sure what the issue is, might be a stock bug. There is nothing in JNSQ that we know of that should affect surface samples. If you're playing career, have you upgraded your R&D facility to Tier 2? Tier 2 R&D is needed to collect surface samples.

I don't have a real good handle on that yet, but my guess is around 0.1

I have the same issue. I think it might be because Kerbin is natively a different size than stock Kerbin. EVE doesn't seem to handle that well. I've seen issues with the main menu view in other planet packs that use a non-standard home world size.

Consider figuring out what you can and cannot do in JNSQ part of the adventure. We didn't want JNSQ to simply be an exact scaled up version of stock It borrows much from stock, but it is reimagined in many ways. You'll have to relearn what you think you know from stock. That's by design. We don't what everything to work just as it did in stock. You may have to find new solutions to old problems.

I gave Tylo an atmosphere simply because I think a body as large as Tylo would have one. I had a hard time rationalizing why to wouldn't have an atmosphere. Undoubtedly the reason Tylo was not given an atmosphere in stock was to provide the challenge of landing on a large airless body, where all the breaking has to be done via propulsion. That's great, but once you've completely the challenge in stock, there's really no need to do it again in JNSQ. So I saw no need to retain Tylo as an airless body. I also greatly reduced Tylo's size, as well and Laythe and Vall. These moons just seemed unrealistically large to me, particularly having two bodies (Tylo and Laythe) that were almost Kerbin size. Reducing their size was also done to, I hope, help stabilize the orbits of the Joolean moons for Principia users. So although Tylo is still big, it's not nearly as large as it is in stock (comparatively speaking). Its surface gravity is only about 1/2 the stock value, so even if I did make Tylo airless, it's not going to provide the same challenge that you get in stock. So rather than repeating something that you've likely already done in your stock game, we've given you 14 new bodies to go explore.

I was not alone in coming to the conclusion that 2.5-ish is about right, but I was one of the early proponents of it. My main goal was to find a scale that used unmodified stock parts, but felt and looked more lifelike in the design of the rockets needed to achieve orbital flight, interplanetary flight, etc. One of my objectives was no SSTO. If SSTO was so easy to achieve, we'd have it by now in real life. I wanted it necessary to use at least two stages to get to orbit, and three stages to go interplanetary. I just started looking at the delta-v requirements at different scales and concluded that 2.5x was about the minimum needed to force players into these multi-stage configurations. Another thing I did was look at some real life rockets and estimated what delta-v they could achieve if they had engine and tank mass ratios comparable to those in stock KSP. My calculations came out to around 5000 m/s, which is about what it takes to get to orbit in KSP at a scale of 2.5x. So both methods pointed to the same answer -- about 2.5x. Of course thinking of things as 2.5x, 6.4x, or whatever seems backwards to me. Real life is the norm, not KSP. Real life isn't 10x scale, real life is 1x. KSP is 1/10th scale (actually closer to 1/11th). So when we think about it that way, we find that 2.5x is close to 1/4 real scale. 1/4 scale just makes a whole lot of sense when you stop to think about it. For instance, when distances and radii are factored by 1/4, orbital periods and delta-v requirements becomes exactly 1/2. The math just works beautifully. 1/4 real scale is actually about 2.7x stock scale, though the difference between 2.5x and 2.7x is small. And besides, before 2.5x became a thing, many people played 3.2x. So 1/4 real scale falls nicely between 2.5 and 3.2.

Glad you like it. That's our own design. I've always found the traditional subway style a bit of a pain to use, so we wanted to do something different. Our hope is that this one will be easier to follow. You still need to delete the curves as I showed you. Then just add the curves back with new numbers. The first number in each key is distance, don't change that. The second number is intensity, multiply those by 1.5. The third and fourth numbers are slopes, they too get multiplied by 1.5.

@jefferyharrell, JNSQ uses sunlight intensity curves that decrease illumination with increasing distance from the sun. The factors used in your patch produce even illumination regardless of distance. They can still be used but are a bit outdated. To get them to work you probably need to delete the curves so the fixed parameters take over. I recommend trying this:

As @JadeOfMaar said, anything orbiting or landed on Minmus will not be affected. When Minmus moves, those vessels move with in. But anything you might have en route will be affected. When a celestial body is relocated, the course of vessels outside its sphere of influence do not change, so they'll no longer intercept the target. A course correction will be require to reacquire the target. It is always best to let vessels reach their destinations before installing an upgrade that relocates a celestial body. In the case of Minmus the travel time is only a few days, so it's unlikely you would upgrade in the middle of a flight. But if the relocated body is a planet, where travel times can be long, this is an issue you may need to consider.

Announcement - Upcoming Change Please be advised that the next version of JNSQ will be making changes to the orbit of Minmus. While this revision is targeted primarily at users of the mod Principia, some changes will affect everyone. Under real life n-body physics, the orbit of Minmus is unstable when positioned outside the orbit of Mun. This instability can be remedied by decreasing Minmus' semimajor axis and moving it inside the orbit of Mun. For users of Principia, this is what we have done. However, some game elements, such as the built-in contract system and world first milestones, are designed around Mun being the closer body. So for non-Principia users we're keeping the system in its stockalike configuration, even though we know that it would be unstable in real life. Consider it artistic license. But while Minmus remains the outermost moon, we're still decreasing the size of its orbit to something a bit more realistic. If any players want to implement this change now and not wait for the next JNSQ release, then just copy the following patch to a .cfg file and save it inside your Gamedata/JNSQ folder. @Kopernicus:AFTER[JNSQ] { @Body[Minmus] { @Properties { !tidallyLocked = DEL !rotationPeriod = DEL tidallyLocked:NEEDS[!Principia] = False tidallyLocked:NEEDS[Principia] = True rotationPeriod:NEEDS[!Principia] = 32400 @initialRotation = 240 } @Orbit { !semiMajorAxis = DEL semiMajorAxis:NEEDS[!Principia] = 146970000 semiMajorAxis:NEEDS[Principia] = 58550000 !meanAnomalyAtEpoch = DEL meanAnomalyAtEpochD = 30 } } @Body[Mun] { @Orbit { !semiMajorAxis = DEL semiMajorAxis:NEEDS[!Principia] = 90960000 semiMajorAxis:NEEDS[Principia] = 93840000 } } } (edit) Also be advised Minmus' textures have been redone, so its terrain will be changing. If you plan on building a base there, you may want to hold off until after the next release. We can't guarantee that anything landed on its surface will survive the update. Hamek's textures have also changed, but it's a long way out there.

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

@4x4cheesecake, my Desert Airfield is fine, it might be that you're using different graphic settings. The Desert site is really finicky. We get it right in one spot, and then it's messed up someplace else. We may not every get it right for all conditions.

It hasn't been discussed, but I would say no. TeamGalileo is finished with GPP and has moved on the next project, JNSQ. JNSQ is still a work in progress, and there are plans to incorporate some of the new features.

I'm planning to release an update that should take care of any ReStock incompatibilities. I have no timetable for it, however.

Since Sigma's plugin has come up, let me explain what it does. It fixes what I think is a flaw in the way stock parachutes work. Parachutes have two deployment modes: (1) semi-deploy, which is a function of atmospheric pressure, and (2) full deploy, which is a function of height above terrain. The problem, as I see it, is that parachutes will full deploy when they reach the height threshold regardless of whether or not they have reached the pressure threshold for semi-deployment. I think this makes no sense; if the air is too thin for parachutes to semi-deploy, they shouldn't full deploy. In stock KSP this really isn't an issue because there aren't any atmospheres that are so thin that the semi-deploy pressure hasn't been reached before the full deploy altitude has been reached. (Maybe on some mountain tops on Duna, but I haven't investigated enough to confirm this) But this "bug" puts a limitation on what planet makers can do with their atmospheres. If a planet maker wants to give a planet an atmosphere, but one so thin that parachutes won't work, he can't. Parachutes are going to full deploy when the height threshold is reached regardless on how thin the atmosphere is made. Sigma's plugin fixes this. Parachutes will not fully deploy unless the pressure for semi-deployment has also been reached. Both conditions must be satisfied for full deployment. In JNSQ, you won't have parachutes popping open 1000 meters above the ground on bodies with very thin atmospheres.

I don't think you sent me any other version other than the one included in JNSQ. If you have one, I should get it from you. I guess we're going to need the source code, unless less you have it on your GitHub somewhere. I know that. I've already proposed revised orbits. But internally the team still hasn't made a final decision about what solution we want to use. I favor putting Minmus inside the orbit of Mun, but we'll see.

Stock physics. It is our intent to make JNSQ stable when used with Principia, but it is designed for use with stock physics.

If I understand you correctly, that's what I did. We can put the vessel in a solar orbit that has an orbital period 5/6th that of Kerbin. So after the vessel completes one full orbit, it returns to its starting position 60 degrees ahead of Kerbin at the L4 point. At least that's the theory. The problem is that Minmus isn't at the L4 point. Any inclination causes it to move up and down, and any eccentricity causes it to move forward and backwards. So in effect, Minmus orbits around the L4 point. So getting an encounter with it isn't a simple matter. In practice I found targeting Minmus very difficult, and the margin for error extremely small. The slightest error will cause a complete miss with no easy recovery. Of course I only tried it a couple times. Maybe it gets easier with practice.

I don't think people asking for a Cruithne-like orbit really know what they are asking for. It's much more difficult than meets the eye. The orbit we tried in testing that @JadeOfMaar refers to was much simpler. It put Minmus in an orbit that hovered around the L4 Lagrange point. And even then transfers were tough. If the ejection was perfectly timed, it could be done for relatively low delta-v, but the windows were really tight. And it took a year to get there and a year to get back. Complicating things further is that Minmus has a really small SOI, so getting an encounter is really tough.

You haven't looked at Eeloo yet, have you?

We actually experimented with that already, but moved Minmus back because we thought it made getting to Minmus too difficult. But it is an option we may have to reconsider. Yep, I suspected from the beginning that Minmus was going to be a problem. It was one of the bodies I was most worried about it terms of orbital stability.