OhioBob

I suggest you go talk to the KSRSS people. Kopernicus being unable to load a planet pack is not a Kopernicus problem, it's a planet pack problem.

I'm not jumping on you. I'm just notifying you that there are no current plans to update JNSQ for the new scatterer. By the way, thanks for letting me know.

Then don't use the new scatterer. I don't know if or when JNSQ will update.

I can't fix a problem I can't reproduce. Your best bet is to strip your installation down to just the following and see if it works. Squad SquadExpansion (if applicable) EnvironmentalVisualEnhancements GEP Kopernicus ModularFlightIntegrator ModuleManager SVE If it doesn't work, then there may be a installation error of some sort, because it works fine for me. If it does work, then start reinstalling mods until it no longer works, and then tell me which mod broke it.

I don't know. JNSQ has been confirmed to work with scatterer v0.772, beyond that it has not been tested. Why don't you install the latest scatterer and then report back to let us know if it works or not? I don't know what scatterer settings you're talking about, but JNSQ includes its own scatter configs.

I don't know, it works fine for me. Of course I don't have the same mods installed as you do. Of the mods on your list, these are the one I have installed: I also have about 15 other mods installed that you don't have. If the problem is with one of the other mods on your list, you're going to have to help me and figure out which one it is, because I'm not going to go and install all those just to test it. But to be honest, I don't know why any of those other mods would have any affect on clouds.

Based on the discussion that has followed, it looks like that when @eddiew said "spaceplane" he did in fact mean a "spaceplane SSTO". For future reference, be aware that just because something is a spaceplane, that doesn't necessarily mean it's an SSTO. For instance, something that has all the characteristics of a plane could get its initial boost from a disposable rocket stage. Or it could have its takeoff thrust augmented by disposable SRBs (rocket-assisted takeoff, or RATO). Or a single stage rocket plane could be lifted to altitude and dropped by another aircraft, thus it wouldn't technically be a SSTO. And an SSTO does not necessarily need to be a spaceplane. A vertically launch rocket could also reach orbit as a single stage. Remember that SSTO means "single stage to orbit", so the vehicle doesn't have to reenter and return intact to be a SSTO, nor does it need to be reusable.

UPDATE Version 0.10.1 Changelog Flipped planet & Strategia icons upright. Revised scatterer settings, sky color is now cast on objects. Revised terrain detail presets; fixed conflict with GPP. Removed color map from AirBaseBoneyard map decal. Added CommNetConstellation compatibility (uses KK ground stations instead of stock). Added optional mod: JavelinEngine (designed for use on Nara). This update does not fix bugs associated with the additional KK launch sites and facilities. These sites are undergoing revisions that will be included in a future update. In the meantime you'll just have to cope with any known problems. Be advised that this version of JNSQ is compatible with scatterer only through v0.0772. Newer versions of scatterer may not work. DOWNLOAD

I'm not a spaceplane person, but from what I've seen and heard, they work fine. But don't conflate "spaceplace" with "SSTO". They're not the same thing.

You should use the latest stable release of Kopernicus, which is suppose to work with KSP v1.10.x. Also make sure you load ModularFlightIntegrator and ModuleManager, which come packaged with Kopernicus. Try loading the planet pack first without Rescale to confirm whether or not it works. If not, then my guess is the problem is likely with the planet pack. You should go to the planet pack thread to seek assistance. What planet pack are you using?

As long as Sigma Dimensions works, which I think it does, this mod should work. Sigma Dimensions hasn't done anything to change it's syntax, so configs written to use it should still work correctly.

Probably caused by some mod interaction. Try uninstalling unnecessary mods and playing DART in a stripped-down installation.

Many mods, and particularly planet packs, don't require updating when KSP updates. As long as Kopernicus is updated, planet packs should work, so there's usually no need to wait for the authors to release an update or officially announce that it's compatible. If you want to try a mod, just install it is and see what happens (though it may be a wise precaution to try it in a new game before using it in a current save).

Support for Principia is not included. You can try it if you want to see what happens, but do so at your own risk and don't ask for support if you run into problems.

While Kronometer has the ability to handle leap years, this is not applicable to JNSQ. Since the years in JNSQ are exactly 365 days, there is no fractional day to carryover, therefore no need for leap years. However, at 1x scale the number of 6-hour days in a year does not work out to be a whole number, but leap years are turned off. With leap years off, the extra time is added at the end of each year as a fraction of a day. While with leap years on, the extra time is accumulated until there is enough to add a full day at the end of a year. In 1x JNSQ the year is about 461.69 days, so we get 461 whole days and a 462nd day that lasts 4h:09m. In 10x JNSQ we again have exactly 365 days, though each day is 24 hours instead of 12 hours.

There is probably nothing to stop DART Range from loading with other planet packs installed, but it is made to fit the stock solar system. Using it in other solar systems is not recommended. Looks good to me. Well done.

I'd also like to add that you folks can thank @JadeOfMaar for the awesome banner art. I love it.

To make the DART Range work as planned, it was necessary to implement some custom code. Below is an explanation of these customizations so you know what to expect should you decide to take the DART Range Challenge. Time Warp Limits Didymos and Dimorphos are very tiny bodies, far smaller than any other planet/moon combination in the game. This really alters one’s perception of distance and speed. If you happen to be on a high-speed approach and using time warp, chances are you’ll fly right on past both bodies before you even see them and have a chance to slow down. It was therefore was necessary to implement a means to drop a vessel out of time warp to prevent accidental overshoot. This is achieved through the use of time warp limits. A vessel traveling at high speed automatically reduces time warp as it nears its target. But there’s more – the limits are dynamic and a function of vessel speed. Therefore, no matter how fast the vessel is traveling, the time interval between reductions is constant. This means you don’t have to concern yourself with reducing time warp while on approach – just sit back and watch the show unfold. Should a vessel happen to slow to orbital velocity (which can be less than 1 m/s), the limits are moved in close to Didymos to allow high time warps from low orbit so one can get around without painfully slow wait times. Thanks to @R-T-B for writing the time warp code. Tidal Locking The tiny moonlet Dimorphos is tidally locked to its parent, Didymos. But because Dimorphos is a part and not a celestial body, implementing and maintaining this proved to be problematic. Special code was added to force the long axis of Dimorphos to always point toward Didymos. This tidal locking code is either on or off, and can be disabled by an impact that sufficiently alters orbit and spin. When the tidal lock is broken, Dimorphos will freely rotate and will never again return to its tidally locked state. The DART mod compares the difference between the rotational and orbital angular velocities to determine if tidal lock has been broken. Whether or not an impact event will do so depends on its force, location, and angle. An impact comparable to the real-life DART mission can break tidal lock if it hits just right. Thanks to @Angel-125 for writing the tidal locking code. Orbit Change Readout So that you can immediately see the effects of an impact on the orbit of Dimorphos, a readout is provided showing the before and after orbital elements. This readout is triggered anytime a spacecraft passes within 250 km of the target, thus near misses will also trigger the display. As R-T-B previously explained, anytime we pass near to Dimorphos its orbit begins to drift, with or without an impact. We believe this to be inherent to the game engine and beyond our ability to control. The unfortunate side effect is that we’ll see a small change in orbit even when we don’t hit the target. If Dimorphos is hit with large enough force, however, large orbital changes can be observed. How much an orbit changes depends on how much momentum is transferred to the target, where momentum is the product of mass and velocity. The real-life 600-kg DART spacecraft will impact Dimorphos at a speed of about 6.5 km/s, transferring momentum of 4 million kg⋅m/s. Thanks to @R-T-B for writing the orbit change code.

You could do that but it might actually hurt rather than help. Wouldn't know without doing the math. There's more involved in it than this, but specific impulse is largely proportional to SQRT(T/M), where T is the combustion temperature and M is the exhaust gas molecular weight. So to get the best performance we want high temperature and low molecular weight. When we add an inert gas, we're lowering the temperature. That's because the heat generated by the combustion of the fuel and oxidizer must heat up the inert gas. Lowering temperature will also increase the molecular weight because there is less dissociation at lower temperature. And depending on what the inert gas is, that could also increase molecular weight. So an engine that adds an inert gas will unquestionably produce a lower specific impulse than one that doesn't. But the question is, does the extra reaction mass more than make up for the lower specific impulse? I don't think there's a one size fits all answer to that question. (edit) We would also need to compress the inert gas so it has adequate pressure to force it into the engine. That means extra machinery, and hence, more mass and cost. So that also needs to be weighed against any benefit we might get in performance.

We're working on something to fix that. While all engines currently in the game won't work at 40 psi ambient pressure, there's no real-world reason why an engine with a high enough combustion chamber pressure couldn't work. Real-life staged combustion engines have well exceeded a chamber pressure of 200 atm. We're planning to provide an optional engine part - a staged combustion aerospike - that will work on Nara.

Neither. We should get 6-hour days and 461 + a fraction days per year (which I have verified in-game to be true). In standard JNSQ (1/4 real scale) we have 365 days per year and 12-hour days. That's 365*12 = 4380 hours per year. At 1/10 real scale (≈stock scale), we're 1/2.5 times the size of standard JNSQ. Therefore we divide by SQRT(2.5) to get the new year duration. That is, 4380 / SQRT(2.5) = 2770.15523 hours. At 1/10th scale we have 6-hour days, so the duration of a year is, 2770.15523 / 6 = 461.6925384 days or 461 days, 4 hours, 9 minutes, 18.8 seconds.

Each JNSQ year is exactly 365 solar days, in which each solar day is exactly 12 hours.

@flart, I assume you updated JNSQ in the middle of an existing save? If that's the case, it's probably best to delete the file, JNSQ/JNSQ_Configs/OffsetTime.cfg. The time offset is really only intended for those stating new games. We're just adding 1/2 rotation to Kerbin and 6 hours to the displayed time so the game starts at 6 UT (sunrise) instead of 0 UT (sunset).

I really have no grand plan on what's the best way of setting time warp limits. I just looked at what Squad did for the stock planets and tried to do something similar. While Squad's numbers seem to be a bit random and inconsistent, I follow a formula for setting the limits with results that are reasonably close to stockalike. (Basically I just look at how long it takes to complete an orbit with increasing altitude, and whenever the period goes over a certain amount of time, I increase to the next time warp.) One rule I do have is that whatever outside a planet's atmosphere, we should be able to warp to at least 50x. When changing atmospheres in the last release, this rule was violated in some instances. Hence the reason for the changes in this release.

UPDATE Version 1.2.5 Changelog Added higher resolution clouds for Nodens and Epona. Fixed bug in clouds heights for Rescale mods. Adjusted time warp limits for new atmosphere heights. Miscellaneous other minor fixes. Be advised that this version of GEP is compatible with scatterer only through v0.0772. Newer versions of scatterer may not work. DOWNLOAD