OhioBob

I thought KAC had upgraded to work with Kronometer, but maybe not. I know at one time it was definitely a problem. In my experience there's just too much that seems to be configured around the 6-hour day that the 90-hour day just didn't work very well. Plus to me it just felt really weird having only 3 long days per year. I've tested the new calendar in GEP but I haven't actually played a game with it, so I don't know how well it will work in practice. If you decide to use it, I'd appreciate feedback. Having months might take some getting use to, but I didn't want to eliminate the 90-hour period altogether, so adding months seemed like a good way to keep it as part of the game. (edit) Now as I think about it, it might be a good idea to modify Belisama's orbit so that each new month starts with a new moon.

Snacks is one of the reasons I decided to go back to the 6-hour day with the most recent upgrade (GEP v1.2.2). It just didn't seem to work well with the 90-hour day. Though I must admit that I really haven't tested Snacks with the new calendar. But I suspect the default setting of 3 snacks per day should cause snacks to be consumed at the same rate as in the stock game. (edit) Even if you haven't upgraded to v1.2.2, you should be able to add the new calendar to your existing install just by copying the file GEP_Primary/Kronometer.cfg from the v1.2.2 download to your installation.

UPDATE Version 1.2.2 Changelog Replaced GEP_JNSQ with GEP_Rescale. Revised Kronometer calendar for GEP_Primary. Revised AtmosphereFromGround for Nodens. Additional compatibility for GEP_CommNet. See opening post for download link and instructions. GEP_Rescale replaces the former GEP_JNSQ. GEP_Rescale can be used to not only change the scale of GEP for integration with JNSQ, but it can also rescale GEP_Primary to 2.5x its normal size. Rescaling is accomplished without the use of Sigma Dimensions. If GEP is used in any installation where Sigma Dimensions is used to perform rescaling, then GEP_Rescale should not be installed. If you are presently using GEP_JNSQ, just delete it and replace with GEP_Rescale. Be advised that Nodens’ orbit is slightly larger and its period slightly longer than it was in GEP_JNSQ. This could affect your save if you are currently exploring that system. The previous calendar for GEP_Primary (Kronometer required) consisted of a 3-day year with 90-hour days (which is also the length of the month). I found this lengthy day a bit awkward to play, so I’ve brought back the familiar 6-hour day from stock. The year is now broken into three months, with each month consisting of 15 days of 6-hours. Clearly a “day” does not have the same meaning as it does to us. I like to think of the 6-hour period as having something to do with the Kerbal work schedule and/or sleep cycle. To make things easy to remember, the three Nodens months have the same abbreviations as our first three months (Jan, Feb and Mar). When playing GEP_Primary + GEP_Rescale, the year consists of four 18-day months. Be advised that Kronometer v1.11.0-1 is required for the new calendar to work correctly.

Kronometer Update Adding to what @Sigma88 just said, you should update Kronometer in your JNSQ installation. Kronometer is packaged with JNSQ, so you'll need to replace the Kronometer found in the following folder, [KSP]/GameData/JNSQ/JNSQ_Plugins/Kronometer with Kronometer v1.11.0-1 downloaded from GitHub. The patch I suggested earlier is not needed if you update Kronometer.

The change is so miniscule that it shouldn't cause any problems. The patch changes Kerbin's orbital period from 364.999999999999 days to 365.000000000001 days. That's a difference of 1 second over 11 million years. However, it's not the size of the change that matters to Kronometer, it's that we went from <365 to >365. I don't pretend to understand how Kronometer works, but apparently that slight change alters how Kronometer executes its logic/computations. In one case we get Year 2 starting on Day 0, and in the other we get Year 2 starting on Day 1. And, as I understand it, the fact that the day has changed really shouldn't affect anything. Internally everything should work off a counter that measures elapsed time in seconds from the start of the game. That counter doesn't change. All that changes is how Kronometer displays the elapsed time as a date. The displayed date can be in any format, it really doesn't matter to anything outside of what you see on your monitor.

Funny thing is, I haven't really explored Brovo all that much myself, and I created it. I'm interesting see what you'll find. I'll probably see stuff I've never seen before. lol

It's likely nothing more will be done on JNSQ, at least not as far as the artwork goes. @Galileo, who developed all the planets, seems to have lost interest and has moved on to other things. I can maintain stuff like if a config needs updating, but beyond that I don't want to mess with it. I want to leave things as is just in case Galileo gets motivated and returns to pick up where he left off.

Should be. I see no reason why there would be a problem.

Presently no plans to do so. That may change someday but no guarantees.

Sigma88 is looking into the issue, but in the meantime the following patch appears to fix the problem in JNSQ: @Kopernicus:AFTER[JNSQ] { @Body[Kerbin] { @Orbit { @semiMajorAxis += 0.0001 } } }

JNSQ only changes useHomeDay and useHomeYear from false to true. Everything else are the default settings, so useLeapYears = false.

The upcoming release of Kronometer, not JNSQ.

Yes. I'm suppose to contact him anyway about something else.

Yes, I have noticed that bug, and I'm pretty sure it's Kronometer. There were some issues with leap years in Kronometer that @Sigma88fixed a year ago, but in the process I believe this bug crept in. Sigma88 just fixed another Kronometer problem dealing with months, which hasn't been released yet. This is probably a good time to review the problem that you point out and try to get it fixed for the upcoming release.

When I design my solar systems, I typically think of them as real life systems and then scale them down in size. JNSQ was scaled down to 1/4 real scale, while GEP was scaled down to 1/10 real scale. So to make GEP the same scale as JNSQ, we multiply by 2.5x. GEP's original 1/10 scale is actually slightly larger than stock. If we assume the stock solar system is a scaled down version of our own real life solar system, then its scale varies depending on how we measure it. The orbits of the four innermost planets are all exactly 1/11 the orbits of Mercury, Venus, Earth and Mars. And if we assume Kerbin and Duna are scale replicas of Earth and Mars, then their radii are at about a 1/10.6 scale. So I just average those numbers and call it about 1/10.8 scale. Since JNSQ is 1/4 real scale, that means JNSQ is about 2.7x stock. And I guess it means that GEP is actually about 1.08x stock, though I just call is stock size because the difference is insignificant.

reDIRECT is the type of parts mod that I want to avoid making changes to. Its parts are designed to work together in a very specific way. Changing the stats of some of those parts would upset the balance.

Grannus' orbit is already made to work with several different planet packs, such as OPM and MPE. But if you need to move it even farther away, you can use the following patch: @Kopernicus:AFTER[GEP] { @Body[Grannus] { @Orbit { @semiMajorAxis *= 2 // a multiplier that can be whatever value you want } } }

That's the problem. HazardousBody worked differently back then. It was changed in the 1.8.1 version of Kopernicus. In older versions the temperature would just continuously increase with no maximum. Everything would eventually blow up no matter what you did.

I'm glad you're liking the mod. Regarding Taranis, yes, there's additional heat added above and around the "Magma Sea". This is done using a feature in Kopernicus called HazardousBody. The extra heat kicks in once you are within 3000 meters of sea level. The ambient temperature begins to rise above the normally computed ambient temperature as you approach the lava surface. At sea level the ambient temperature reaches a maximum of 1500 K, so given enough time, your vessel should eventually heat up to that temperature. Parts that cannot resist at least 1500 K are at risk of exploding. The same thing occurs in the "Magma Shores" biome, though the sea level ambient temperature is 1000 K. Outside of those two biomes, all temperatures are computed as normal.

https://www.dropbox.com/s/gcuxvxdnp8yz3cg/JNSQ_PlanetData.zip?dl=0

I made a mistake there on the pressure; it's 4.5 MPa (or about 44.4 atm). Of course that's the average; the maximum can be considerably greater. I don't know off the top of my head what the units are for the coefficient, but I do know it's calibrated to take pressure in MPa and give burn rate in mm/s. By the way, the coefficient and exponent are the values for the Space Shuttle SRBs. NASA publications give the coefficient as 0.0386625, but that's for pressure in PSI and burn rate in inch/s. I converted it to metric.

When I did the calculations for the SRBs I simplified things somewhat and didn't really get into that level of detail. But I do have all those parameters from when I computed the thrust curves. Burn rate coefficient = 5.6059 // pressure in MPa, burn rate in mm/s Pressure exponent = 0.35 Combustion chamber temperature, average = 3330 K Combustion chamber pressure, average = 4.5 MPa Propellant density = 1500 kg/m³ Specific heat ratio and molar mass become messy because there are solids in the exhaust. It's not a clean cut as when the products are all gaseous. I'm not familiar with OpenMotor, so I'm not sure what information you require. The method I used in my calculations are those presented by Richard Nakka in his Experimental Rocketry web site, which I've reproduced in part on my web site: http://www.braeunig.us/space/thermo.htm#condensed Here are the average values used: Specific heat ratio, gas = 1.270 Specific heat ratio, mix = 1.176 Specific heat ratio, 2-phase = 1.070 Molecular mass, gas = 18.97 kg/kmol Molecular mass, effective = 27.67 kg/kmol

Release Kopernicus R-T-B Unified "Bleeding Edge" Edition Release 58 · R-T-B/Kopernicus · GitHub

On Kerbin, no change. On other planets, I don't know.

I haven't tested it myself, but as I understand it, yes, v0.0722. Apparently the new version requires some config changes. I suspect that any planet pack that hasn't been updated specifically for v0.0722 won't work. GEP should work fine with v0.0632. (edit) I just tested GEP with scatterer v0.0723 and everything seems to be working fine. Apparently the reported bug was a problem with scatterer v0.0722. It appears that no changes to GEP are required.