OhioBob

Below are my estimates of the delta-v require for interplanetary transfers between Kerbin and the listed planets. Computations are for a Hohmann transfer with a mid-course plane change. Delta-v varies from one launch window to the next, so the values are given in ranges. Your results could be different depending on your transfer method. Moho Eve Duna Dres Jool Eeloo Ejection m/s 1810-2750 1100-1120 1120-1220 1780-2140 2510-2610 2530-2980 Plane change m/s 0-2320 0-500 0-12 0-990 0-260 0-1260 Capture m/s 3390-5140 185-225 330-530 1250-2080 280-340 1080-2370 Low orbit insertion m/s 295 1280 360 150 2770 235 Total Δv m/s 6630-9990 2600-3070 1900-2040 4020-4920 5620-5900 4910-6330 Time of flight days 32-38 48 81-89 143-198 297-336 304-606

I don't know what the ghosted circle is. The planets being more dimly lit is by design. In stock KSP sunlight does not diminish with distance - it is infinite. That doesn't work when there are multiple stars or else everything will be brightly lit by all light sources. GPP_Secondary add "sunlight intensity curves" to reduce the illumination as we move farther away from a star. Eventually the light fades to zero, so planets orbiting the Sun aren't illuminated by Ciro, and those orbiting Ciro aren't illuminated by the Sun. The OPM planets lie far from the Sun so they are more dimly illuminated. Without GPP_Secondary you are seeing them illuminated with the same amount of light as the inner planets.

Replace the following file, GameData/GPP/GPP_Scatterer/Configs/OPM_planetsList.cfg with this one, https://www.dropbox.com/s/pebry2onu46bbdk/OPM_planetsList.cfg?dl=0 That should fix the problem.

I recently was just looking at asteroids in the stock game for something else. I was typically getting about 7 or 8 around Kerbin at any one time. They had really short untracked lifetimes, however. Like about 40-80 days as I recall. I'm not sure why we have such long lifetimes in GPP. I'm thinking that we may need to reexamine that decision. There might not be anything wrong with your original solution -- !Asteroid:HAS[~author[*]]:NEEDS[!GPP_Secondary]{}. It could be that wasn't working only because you were testing it in an old save. In a new game it might work, and it should produce asteroids in both star systems. Regarding how to get asteroids to spawn in the stock system in your current save, I'm afraid I really don't know. Perhaps it just needs more time.

Deleting the cfg will stop asteroids from spawning in the Ciro system. That's to be expected. But I don't know why they're not spawning in the stock system. Can you try starting a new game to see if they spawn?

I would have thought !Asteroid:HAS[~author[*]]:NEEDS[!GPP_Secondary]{} would work. You could try deleting that line altogether. And if you don't care about asteroids spawning near Gael and Ciro, just delete Asteroids.cfg.

What atmospheres and broken and what about them is broken? I've had no problems with atmospheres and, as far as I know, nothing in the recent KSP releases should have affected atmospheres at all.

I've never seen or heard of a problem like this before. I can't speculate as to what might be causing it. You may have to systematically remove your mods until you can identify which one is be causing the conflict. Short of that, there's not much else I can recommend. That's a known issue. The JNSQ options only appear the first time you go into your settings. But you typically only need to set it once. After that you'll get whatever you set it to the first time even though slider may no longer show all the options. It's not a problem, so don't worry about it. If you've moved the slider around and feel you made need to reset it to be certain you have the correct setting, the only way to get the JNSQ options back is to delete the file settings.cfg in your KSP folder. Deleting that file will force you to redo all of your settings.

Tidally Locked Kerbin Tidally Locked Kerbin is a mod for Kerbal Space Program that reimagines Kerbin as a tidally locked world orbiting a smaller and dimmer Sun. Kerbin is completely redone with new terrain and textures. One side is a hot desert forever bathed in sunlight, while the other side experiences the cold of an unending night. In between these extremes lies a wet and lush habitable zone. While Kerbin is brand new, most other things about the stock system remain the same. The changes made are brought about only by the need to account for the smaller Sun. While some of the changes are subtle, they impact the game enough to alter the game playing experience. This mod is for players who want to start over and shake things up just enough to have to rethink some strategies. Download (GitHub) Mod Highlights Aside from Kerbin, all celestial bodies retain their stock appearance. The Sun is now a K-type main-sequence star, having about 60% the mass and 14% the luminosity of the stock sun. While the Sun is now smaller, its apparent size in Kerbin’s sky is unchanged. All planetary orbits have been reduce to about 37.5% of their stock values so that each planet continues to receive the same amount of sunlight. Kerbin now lies at a distance of about 5.1 million kilometers from the Sun. Along with Kerbin, Moho and Eve are also now tidally locked. Planets beyond Kerbin are far enough from the Sun to have escaped the fate of tidal locking. Because planets lie closer to the Sun, they have smaller spheres-of-influence. Kerbin’s SOI is now about 37,000 kilometers. Orbits of Gilly and Minmus have been reduced in size to keep them inside their planets' SOI. This is the only change to any of the moons. Kerbin retains its 6-hour day, though a "day" no longer has the same meaning as it does for us. Perhaps it is defined by biological rhythms rather than astronomy. Planets now orbit faster with shorter orbital periods. Kerbin’s year is now 120 days in length. Travel times between planets are much shorter, about 28% as long, saving on consumables if life support mods are used. Delta-v requirements for interplanetary flights are greater, varying from about 10% to 35% more depending on the planets involved and the technique used. Eastward launches from Kerbin no longer benefit from the planet’s rapid rotation, thereby requiring more Δv to attain orbit. On the flipside, westward launches are just as easy. Synchronous orbits are no longer possible around Kerbin and Eve. While the atmospheric pressures on Kerbin and Eve are unchanged, temperatures have been reworked consistent with being tidally locked. Kerbin retains all of its launch sites and anomalies, located at the usual coordinates. Tidally locked planets are oriented so that their prime meridians (0° longitude) face the Sun. This orientation places KSC conveniently in daylight near the western terminator, making eastward launches over sunlit terrain. Unfortunately the Woomerang and Desert sites are located on the dark side of the planet. To compenstate, a new daylight space center is added using Kerbal Konstructs. Only 13% of Kerbin’s surface is water, compared to 52% in stock. Kerbin contains 20 biomes, 9 more than stock Kerbin. Requirements Kopernicus ModularFlightIntegrator Module Manager Recommended Mods Kerbal Konstructs – Adds a new space center, designed by @JadeOfMaar. Kronometer – Changes the calendar year to 120 days. Provided Compatibility Tidally Locked Kerbin (TLK) is fully compatible with Scatterer, Environmental Visual Enhancements (EVE), and Stock Visual Enhancements (SVE). TLK provides its own configs and textures that overrides all others, while scatterer, EVE and SVE will apply their visuals to the remaining bodies. TLK is also compatible with Realistic Atmospheres. When installed together, TLK provides new atmospheres for Kerbin and Eve, while Realistic Atmospheres provides atmospheres for the remaining bodies. TLK works seamlessly alongside Outer Planets Mod and Minor Planets Expansion. Planetary orbits are rescaled to maintain their proportional relationship with the stock planets. Licensing This mod is licensed by Creative Commons Attribution-NonCommercial-NoDerivs CC BY-NC-ND Review of Tidally locked Kerbin by KottabosGames:

Need more information. For starters, what other mods do you have installed (e.g. scatterer, EVE)? Also, what versions of everything are you using.

Eclipse shadows in JNSQ are produced by scatterer when they fall on an atmospheric body, or EVE when they fall on an airless body (or when scatterer is not installed).

Grannus Expansion Pack appears to be working OK with Kopernicus Continued, a fork of the original Kopernicus recompiled for KSP 1.9.1. If anyone discovers problems, please report them here and I'll try to determine whether the issue is with GEP or Kopernicus.

Nope.

GPP and GEP are both designed to work just fine without EVE and scatterer, but the visuals will be comparable to stock. No clouds, no scatterer sunsets, etc. Your performance, however, should be much better.

@RocketRyleigh, below are JNSQ's RemoteTech changes. Perhaps it will make some sense to you. It looks to me like it's just multiplying all the antenna ranges by 4. // RemoteTech @PART:HAS[@MODULE[ModuleRTAntenna*]]:NEEDS[RemoteTech]:LAST[JNSQ] { @MODULE[ModuleRTAntenna*] { @OmniRange *= 4 @Mode1OmniRange *= 4 @Mode1DishRange *= 4 %JNSQ = True } }

JNSQ's antenna config includes patches to RemoteTech, so I assume it's modified in a way that's consistent with our recommendations. Unfortunately I don't know anything about RemoteTech, so I don't understand what the patches are doing. Perhaps @JadeOfMaar can explain.

No it doesn't. It's a gas giant.

Ah, that's right. I forgot that GPP hasn't been updated to use the new heating feature in Kopernicus. I've made the change but it hasn't been released.

Our recommendation for JNSQ is to not use SMURFF at all. The entire purpose of making JNSQ 1/4 real scale (~2.7x stock) is to make rockets built using unmodified stock parts look and perform more lifelike. Modifying the parts with SMURFF defeats that purpose. Of course you can play anyway you want (far be it from me to tell you how to have fun). But I suggest you try JNSQ without SMURFF first to see how you like it before changing it. Many players seem to believe that JNSQ is the "goldilocks zone" for planetary scale using stock parts.

JNSQ Eve's atmosphere is only thicker than stock Eve's atmosphere at low altitudes. Above about 5800 m, JNSQ Eve's atmospheric density is actually lower than stock Eve, and it is only 60 km high instead of 90 km. Also stock Eve has a higher surface gravity (1.7 g vs. 1.4 g in JNSQ), so there are greater gravity losses in stock. One extra note about my 7000 m/s number for JNSQ, that was for a nice streamlined rocket that I teleported into place. I didn't actually land it on Eve. Thus I didn't have to make something capable of entering Eve's atmosphere, landing, and being stable the entire time. Something built to be capable of entry and landing may not be quite so aerodynamically friendly on ascent. Therefore the delta-v could be higher.

I don't want to give too much away, but the most hazardous areas are associated with a couple biomes. In the worst case your parts could heat up to as much as 2500 K, but that's the exception. In most cases your parts might get hot, but not hot enough to fail. There are also areas in orbit where your vessel can heat up.

@Space Nerd, I've been doing some math and, presuming I didn't mess up the calculations, it looks to me like Tylo is definitely capable of ejecting a spacecraft from Jool orbit given the right circumstances.

We don't know. What one can do in regard the gravity assists we've left up to the players to figure out. (edit) Of course it is going to depend on the circumstances. If the spacecraft is already traveling at a high speed close to escape velocity, then surely Tylo would be able to give the extra kick needed to eject it from the system. But if the spacecraft is traveling very slowly as it approaches Tylo, then it likely wouldn't get ejected. So with the limited amount of information you've given, it is impossible to answer. We would need to know the specific details of the encounter between moon and spacecraft to make a determination. We wanted our Laythe to look more dreary than the stock version.

From my experience, you don't calculate the orientation. You just figure out by trial and error what best fits the surrounding terrain.

You have to change latitude and longitude to a position vector. A vector of 1,0,0 points to 0 latitude, 0 longitude. If you tell me your latitude and longitude, I can do the conversion for you. Instead of using a position vector, I think you can also do something like, position { latitude = longitude = } but I'm not sure of the syntax. You might have to give an altitude as well.