OhioBob

JadeOfMaar is going to look into the KK issue. He's our man on everything KK related. As far as the terrain detail presets go, ideally I'd like the slider to show only the JNSQ options, and then have GPP use the same setting. That is, we pick JNSQ_High so we automatically get GPP_High as well. I'm hoping I can figure out some way to use NEEDS[] to accomplish that. I guess I've never noticed this before because I usually install JNSQ first and run the game to verify installation before adding GPP and company. So before GPP is installed I've already completed the game settings.

Interesting, I was not aware that conflict existed. I'm not sure how I can fix that, will need to investigate. In the meantime, I'd suggest JNSQ_High. Since JNSQ is the primary system in which you will be spending most of your time, it makes sense to have the JNSQ terrain looking its best. I'm not sure, however, what that will do to the GPP terrain.

@Bombaatu, @jefferyharrell Can either of you guys confirm for me whether the icons are flipped vertically, or rotated 180 degrees? In other words, are the I, II and III markings suppose to be on the bottom-left or the bottom-right? (edit) Can one of you guys check these in game? Just replace the ones in your install with the following. They are located in the folder JNSQ/JNSQ_Textures/Icons. I might have done them incorrectly. They should be right-side-up now, but I might have to flip them again horizontally. https://www.dropbox.com/s/a53s8bysvzp9nyj/Icons.zip?dl=0 (edit2) I just found some screenshots from Strategia and I'm pretty sure I have them all backwards. (edit3) I think they're correct now, but if anyone can check them for me it's appreciated.

LOL. All the icons were converted from .dds to .png. But .dds must be flipped vertically, while .png does not. So whoever did the conversion apparently forgot to flip them. We know about the non-compatibility thing, though I'm not sure if there's a solution. The problem is that both JNSQ and GPP are natively primary star systems that replace the stock system. Thus, as far as CKAN is concerned, they can't co-exist with each other. They are only compatible with the addition of GPP_Secondary. When all the options were set up, I only considered manual installation. Never gave any thought to CKAN because, quite honestly, I have no idea how it works. Yes, those are needed as well.

That's correct. I noted that adding Rescale to an existing save is not recommended, but in this case you shouldn't have any problem since you're not changing the size of JNSQ. And, yes, you should be able to add GEP at a later time, using GEP + GEP_Rescale (2.5x).

If you haven't already done so, delete the settings.cfg file inside your root KSP folder and restart the game. Then select the GPP_High* setting for terrain detail. Make sure to also set all the terrain and rendering settings to their maximum. (You'll also have to reselect all your other settings as KSP rebuilds the deleted cfg.) This might help. If not, I'll need more information. * At present it might show something like "#LOC_GPP_TerrainDetailPreset_High" because we accidentally omitted the description from the localization files. It should be the far right setting on the slider. GPP textures have only one resolution. Only the clouds have high and low resolution options.

I've asked him to update it, but he doesn't have much free time these days. He'll get to it eventually.

Apparently you didn't do anything wrong because it's underground for me too. I'll have to figure it out. An update might be forthcoming, but I want to wait awhile to see if any other problems turn up. (edit) If I find the solution I'll post a patch here so you don't have to wait for a new release.

What you describe is exactly true. So it makes sense that JNSQ and GPP might show as incompatible.

I don't know anything about how CKAN works, never used it. I know that JNSQ 0.10.0, GPP 1.6.6.0, and GEP 1.2.4 are compatible, along with the optional mods that come with them. If installed manually everything should work. CKAN may not be set up correctly, or perhaps there's a bug in one of our mods that is preventing it from working. Either way, it's beyond my current knowledge to fix. I recommend you install manually whatever CKAN is not allowing you to install.

You're not crazy. Several months ago I completely rewrote the spreadsheet that I use to compute atmospheres. Couple that with the fact that all three Team Galileo planet packs (JNSQ, GPP and GEP) can now exist together in three different scales (1x, 2.5x and 10x), I felt the need to redo all the atmospheres to assure they all conform to the same standard. That resulted in new heights for many of the atmospheres, including JNSQ Kerbin. My previous response was partly in jest. When I get a chance I'll play around with the scatterer settings to see if I can make it look any better. But honestly, if that's the only change, I doubt I'll release an update. But I wouldn't be surprised if other issues turn up that require fixes. If so, there could be a 0.10.1 patch.

Maybe I'll make that change for the next release, which, if history is any guide, might be sometime around spring 2023.

I computed that number too, using the same method. The 216.2 s number I got this way... Specific impulse is typically computed as thrust/(fuel flow rate*go), but I figure we could also take (thrust*time)/((fuel flow rate*time)*go). Of course thrust*time is the total impulse of the rocket, and fuel flow rate*time is just the total amount of fuel. I compute the burn time of the SRBs to be 23.69 s and that of the Reliant to be 101.34 s at full thrust. Therefore, ((197.897 * 3 + 205.161) * 23.69 + 205.161 * (101.34 - 23.69)) / (16.4375 * 9.80665) = 216.23 s The same number can be arrived at more simply this way, Σ(fuel mass*Isp)/Σ(fuel mass). (8.4375*170 + 8*265) / (8.4375 + 8) = 216.24 s The 220.84 s number is probably more correct, but I doubt KER would compute it that way. I was attempting to find a method that I though KER might use to compute the combined Isp. Of course neither method nor any other method I tried would reproduce KER's 224.6 s number. I don't know where that comes from.

When I do it, I pitch over almost immediately and start accelerating horizontally. Just make sure you get enough altitude to clear the terrain and not crash into a mountain. I also usually go eastward, though that's not necessarily a must. As soon as the apoapsis reaches a sufficient height, say 10-15 km, cut the engines. Now coast up to apoapsis and burn the engines again to circularize the orbit. This will place you in a safe parking orbit around Ceti (or whatever moon it is). The next thing to do it perform the burn to set the vessel on a trajectory back to Gael. It's been a long time since I returned from Ceti, but I think the correct location to perform the burn is at about 135° from retrograd. In other words, let say we have a clock face with 12:00 pointed toward Gael. If orbiting eastward (retrograde), then set the maneuver node at about the 1:30 position, and if orbiting westward (prograde), at about 4:30. You want to make it so the trajectory of the vessel as it leaves Ceti's sphere-of-influence is roughly parallel to Ceti's orbit and traveling in a retrograd direction. You want the trajectory to intercept Gael at a periapsis that is neither too high nor too low. I generally target a periapsis altitude of about 25 km. Doing as I describe above, I think a reasonable amount of delta-v to budget is 600 m/s for the ascent to orbit, and 250 m/s for the return trajectory to Gael. And if you're really efficient, you should be able to beat those numbers.

You don't have much to spare but that should be enough. According to the dV map, it ought to take about 755 m/s.

I don't know, I'll have to look into that. (edit) I can confirm that it has always been set to zero. Nothing has changed since v0.9.0. (edit 2) The sunrises and sunsets look pretty colorful to me. I don't see a problem.

Thanks. I've merged your request.

Further Explanation of Rescale mods... The optional Rescale mods are designed to allow JNSQ, GPP and GEP to be installed either together or individually in a variety of scales. These mods work without the use of Sigma Dimensions and should never used in combination with Sigma Dimensions. The scales are defined as follows: 1x – 1/10th real scale, or approximately stock size. This is the native size of GPP and GEP. 2.5x – 1/4th real scale, or approximately 2.5x stock size. This is the native size of JNSQ. 10x – Real scale, or approximately 10x stock size. (Note that stock KSP is actually closer to 1/11th scale.) JNSQ can only exist as the primary star system, i.e. the planetary system orbiting the central star. No other options exist for the installation of JNSQ. GPP can be installed as the primary star system only if JNSQ is not present. It can also be installed as a secondary star system to either JNSQ or GEP, using the optional mod GPP_Secondary. GEP can be installed as the primary star system only if JNSQ is not present, using the optional mod GEP_Primary. It can also be installed as a secondary star system to either JNSQ or GPP, or as a tertiary star system if both JNSQ and GPP are present. In summary, the following are possible: JNSQ JNSQ + GEP JNSQ + GPP + GPP_Secondary JNSQ + GPP + GPP_Secondary + GEP GPP GPP + GEP GEP + GEP_Primary GEP + GEP_Primary + GPP + GPP_Secondary To be installed together, all planet packs must be sized to the same scale. Example #1 We want to install all three planet packs sized to 2.5x scale. Since JNSQ already exists at 2.5x, it does not require resizing. However, GPP and GEP are both natively 1x, therefore we must install the 2.5x version of GPP_Rescale and GEP_Rescale to match the size of JNSQ. We install the following mods: JNSQ + GPP + GPP_Secondary + GPP_Rescale (2.5x) + GEP + GEP_Rescale (2.5x) Example #2 We want to install all three planet packs sized to 1x scale. GPP and GEP already exist at 1x, so resizing is not require. However, JNSQ must be resized to 1x scale to match the smaller size of GPP and GEP, therefore we must install the 1x version of JNSQ_Rescale. We install the following mods: JNSQ + JNSQ_Rescale (1x) + GPP + GPP_Secondary + GEP Example #3 We want to install all three planet packs sized to 10x scale. Since none of the planet packs natively exist at 10x scale, all three must be resized using the 10x version of their Rescale mod. We install the following mods: JNSQ + JNSQ_Rescale (10x) + GPP + GPP_Secondary + GPP_Rescale (10x) + GEP + GEP_Rescale (10x) It is also recommended that you delete the Kopernicus cache when using Rescale for the first time. These are the *.bin files located within each planet pack's Cache folder. This should be done anytime the size of a planet pack is changed, but needs to be done only one time per size change. It is also recommended that the DSN modifier in game difficulty be set to a value appropriate for the size of the solar system. The following are some suggested guidelines: If JNSQ is installed: set DSN modifier to 1.6 for 1x scale, or 4 for 2.5x scale, or 16 for 10x scale. If GPP is installed as primary: set DSN modifier to 1 for 1x scale, or 2.5 for 2.5x scale, or 10 for 10x scale. If GEP is installed as primary: set DSN modifier to 1 for 1x and 2.5x scales, or 4 for 10x scale. PartRebalancer10x PartRebalancer10x is an optional mod that makes changes to the mass of parts and the density of propellants to give rockets more life-like mass ratios so they can attain the higher performance necessary when playing at real scale (10x). It is provided as a simple alternative to using mods such as Realism Overhaul, ROMini, or SMURFF. While PartRebalancer10x certainly doesn't provide the same level of realism as Realism Overhaul, it does allow you to jump in and immediately start playing at 10x scale with parts properly balanced for the task. PartRebalancer10x is an ideal stepping stone for first-timers to 10x scale who want to experiment before making the jump to Realism Overhaul. We recommend the addition of BetterSRBs for even more like-life solid rocket performance. PartRebalancer10x is not recommended for scales smaller than 10x.

UPDATE Version 1.2.4 Changelog Added Optional Mods: GEP_Rescale for 2.5x and 10x versions of GEP. Revised atmospheres (surface pressure unchanged, heights different). Revised rotation periods of Sirona, RAB-58E & Cernunnos. Revised flying altitude thresholds. Revised NavBall switch radius multipliers. Revised scatterer atmosphere textures and configs. Revised EVE Clouds for better compatibility with other mods. Revised Taranis' lava texture and color. Revised RAB-58E's fade limits to fix frame rate drop. Updated CelestialBodies.pdf. This update includes many important updates, bug fixes, and improvements. This update is certified to work only with KSP 1.12.1 or newer. It may work with older KSP versions, though it has not been tested and support will not be provided. Atmospheres have been redone to provide conformity across all Team Galileo products. There is nothing about this update that is anticipated to break existing saves. Adding GEP_Rescale to an existing save is not recommended. For more information about Rescale mods, read here. DOWNLOAD

UPDATE Version 1.6.6.0 Changelog Added Optional Mods: GPP_Rescale for 2.5x and 10x versions of GPP. Added extra launch sites to MechJeb2 config. Added HazardousBody to gas giants. Updated scatterer configs and fixed bugs. Updated CelestialBodies.pdf. Updated KK things to only be read when KK is installed and not when GPP_Secondary is installed. (No more KSC++ on Squad Kerbin.) Revised atmospheres (surface pressure unchanged, heights may be different). Revised rotationPeriod and/or intialRotation of many celestial bodies. Revised flying altitude thresholds. Revised NavBall switch radius multipliers. Revised Lili's fade limits to fix frame rate drop. Deleted MyRocksAreBiggerThanYours plugin (now part of Kopernicus). Deleted GPP KSPedia (doesn't work in current KSP version). Deleted unused MapDecal and FlattenArea in GPP_Secondary. Miscellaneous other fixes and updates. This update includes many important updates, bug fixes, and improvements. This does not include any of the texture or terrain changes that have been hinted about (that's still a work in progress). We're releasing these changes ahead of schedule to correspond with similar updates to JNSQ and GEP. The update is certified to work only with KSP 1.12.1 or newer. It may work with older KSP versions, though it has not been tested and support will not be provided. Atmospheres have been redone to provide conformity across all Team Galileo products. The changes to rotation periods and initial rotation may break existing geosynchronous satellite networks. Additionally, moon bases may find themselves facing a different direction - perhaps no longer with a line-of-sight to the planet. If you suspect your existing save may be damaged, then either consider not updating, or be prepared to redo, abandon, or correct the damage. Adding GPP_Rescale to an existing save is not recommended. For more information about Rescale mods, read here. DOWNLOAD

UPDATE Version 0.10.0 Changelog Added dark mode dV map. Added one biome each to Dres and Edna. Added Optional Mods: JNSQ_Rescale for 1x and 10x versions of JNSQ. Changed Eeloo's rotational period to 8 hours. Changed game start time to 6:00 UT--sunrise at KSC (requires Kronometer). Converted celestial body icons to .png (thanks to @yalov cn GitHub). This fixes issues with Strategia and Waypoint Manager. Fixed Bop's rotation to retrograde for Principia users. Included RemoteTech in antenna range multiplier (thanks to @armegeddon cn GitHub). Included part upgrades in antenna range multiplier (thanks to @jsolson cn GitHub). Revised atmospheres (surface pressure unchanged, heights may be different). Revised CelestialBodies.pdf (atmosphere changes). Revised flying altitude thresholds. Revised NavBall switch radius multipliers. Revised asteroids so that they better populate the desired fields. Reduced Minmus' science values for Principia users. Reduced SCANsat altitude multipliers from 3x to 1.5x. Removed KerbalHealth config. KerbalHealth has chosen to host all JNSQ configs in itself. Removed Kronometer from JNSQ (must now be downloaded and installed separately). Removed MyRocksAreBiggerThanYours plugin (now part of Kopernicus). Removed Rational Resources bundle. Updated TweakChutes to hopefully properly respond to FAR/RealChute. Updated KK: Added three more space centers. (Hidden) Added runway section to S. Musgrave. Added barracks to all bases that were missing them, including observatories. Buffed barracks capacities at astronaut complexes. Fixed duplicate launch site names for helipads and rovers. Fixed orientation or offset of some bases. Fixed west vs east runways. This update includes many important updates, bug fixes, and improvements. This update is certified to work only with KSP 1.12.1 or newer. It may work with older KSP versions, though it has not been tested and support will not be provided. Atmospheres have been redone to provide conformity across all Team Galileo products. This update adds an extra 1/2 rotation to Kerbin's initial rotation. This could break existing geostationary satellites if they are strategically placed over specific landmarks. This change can be reverted by deleting the file JNSQ_Configs/OffsetTime.cfg. Adding JNSQ_Rescale to an existing save is not recommended. DOWNLOAD

I've been trying to figure out how KER comes up with that 224.6 s number but I can't reproduce it. Computing the average Isp over the entire burn (as king of nowhere suggests), I come up with a number of 216.2 s.

@VoidFoo, your calculation is correct, it looks like KER is wrong. I built the same rocket as you and I'm seeing the same numbers in KER. However, if you look at the built-in KSP dV indicator, it shows the Isp as 187 s, which agrees with you. I also confirmed the correctness of your calculation by performing an in-game test. I sent the rocket to the launchpad, ignited the engines, and ran it until the SRBs burned out. This took about 24 seconds, during which we burned 1125 units of solid fuel, 210 units of oxidizer, and 172 units of liquid fuel. That's a total mass of 10.3475 metric tons of propellant, which gives us a propellant flow rate of 10.3475 / 24 = 0.43115 t/s. Thus, the specific impulse is, Isp = thrust / (flow rate * go) = 798.85 / (0.43115 * 9.80665) = 189 s I'm off a little bit from your calculation because of error in my measurements. But as far as computing the delta-v is concerned, @king of nowhere is correct, you have to consider it a 2-stage rocket. You must compute the dV for the first 24 seconds when all engines are running, and then compute separately the dV for the period of time when just the Reliant is running and burning what propellant remains. You might want to report your findings in the KER thread so perhaps the dev can fix the error.

@Araym, I haven't tried Custom Barn Kit recently so I can't provide any insight there. However, you can achieve some of the same effect as the Level 4 Tracking Station by adjusting the DSN range in the game difficulty settings. In the difficulty settings you should find two sliders - DSN Modifier and Antenna Modifier. The Level 4 Tracking Station has a range 8 times that of the Level 3. So if you change the DSN Modifier to 8, then that would give the Level 3 Tracking Station the same range as the Level 4, thus achieving the same end-game result. Of course this would also increase the range of the Level 1 and Level 2 Tracking Stations as well, making the game easier in some regards. You can also increase the Antenna Modifier, which increases the range that one antenna can communicate with another antenna. (The DSN modifier only increases the range between an antenna and the network of receiving stations on Kerbin.) However, the last time I tired it, the Antenna Modifier was bugged if it was set to anything other than 1. (Setting it to other values sometimes prevented the transmission of science.) I would be hesitant to try this without testing it out first. While it might not be a good idea to change the Antenna Modifier because of the bug, note that the two range modifiers are multiplicative. The range between DSN and antenna is increased by a factor of SQRT(DSN Modifier * Antenna Modifier). The J2X antenna is another good option. It has a power 10 times that of the most powerful stock antenna (the Communotron 88-88). Note that in neither case, an 8x increase in DSN Modifier nor the use of a single J2X antenna, is the range increased enough to reach Plock when near its aphelion. To reach Plock when at its farthest distance, you would need to start combining antennas - either by placing more antennas on your probe or by using a relay.

Correct, there is no special HeatShifter config required. The only thing that must be added is the line "maxTempAngleOffset = 0" inside the Atmosphere node of the planet's config. My spreadsheet already adds this, so as long as you copy and paste from my spreadsheet to your config, you should be good. In fact, the offset angle can be anything you want it to be. A value of zero means that the hottest time of day occurs at noon (or at the subsolar point for a tidally locked planet). An offset angle of 45 degrees means the hottest time of day occurs midway between noon and sunset. (An offset of 45° is hardcoded into stock KSP.)