[1.12.5] Grannus Expansion Pack [v1.2.8] [10 May 2022]

OhioBob · December 2, 2020

4 hours ago, Souptime said:

Is grannus supposed to be that close? i do have OPM installed but its close even for stock, like right next to plock or around 2X the distance of eeloo for stock

That doesn't sound right. Grannus' periapsis is suppose to be 1,200 gigameters. That's about 13 times Eeloo's distance in stock, and about twice Plock's distance.

Souptime · December 2, 2020

Oh, well its not in my game. dont have any hyperedit configs for it either. i've had it installed before but then i uninstalled it then yesteray i reinstalled it

mLeiska · December 13, 2020

Can this mod be paired with the Extrasolar mod which adds the Valentine system?

OhioBob · December 13, 2020

3 hours ago, mLeiska said:

Can this mod be paired with the Extrasolar mod which adds the Valentine system?

I don't know. You can try it and see what happens.

Souptime · December 15, 2020

Works for me!

PocketBrotector · December 17, 2020

@OhioBob, I'm interested in adding GEP_JNSQ to the Launch Window Planner for JNSQ. I'm able to get most of the needed body/orbit parameters from the config files or CelestialBodies pdf (thanks for including that, by the way), but there are a couple of derived stats that I think might be changed indirectly when the planets get resized for JNSQ. I don't know enough orbital mechanics to calculate them confidently myself... do you have these in a spreadsheet somewhere, or maybe there's a formula you can share?

The stats in question are, for each body in GEP:

Sidereal rotation period
Mass

The stats I already have from GEP_Bodies, modified by GEP_forJNSQ:

Semi-Major Axis
Eccentricity
Inclination
Longitude of Ascending Node
Argument of Periapsis
Mean Anomaly at Epoch

Thanks!

OhioBob · December 17, 2020

@PocketBrotector

As you say, the last group of parameters are all obtainable from the configs, and they are exact values. Most of the other stuff is derived, as follows:

gravParameter (m³/s²) = geeASL * 9.80665 * radius^2

mass (kg) = gravParameter / 6.67408E-11

orbital period (s) = 2 * pi * SQRT( semiMajorAxis^3 / gravParameter_{[primary body]} )

Rotation periods are unchanged except for tidally locked bodies (where rotation period equals the orbital period), or if specifically changed in GEP_forJNSQ.cfg.

If there's anything else you need, please ask.

Edited December 17, 2020 by OhioBob

PocketBrotector · December 18, 2020

@OhioBob Thanks!

I've now updated the launch window planner to include all bodies in GEP_JNSQ. Initial comparisons to the Transfer Window Planner mod shows fairly consistent results (~15k dV for Kerbin -> Grannus/Nodens in 60-70 years; ~40k dV for Nodens -> Taranis in 7 days; etc.)

ra4nd0m · December 22, 2020

I've been testing this mod on1.11 and got logspam with EVE installed. EVE itself without GEP works fine. Logspam starts only with GEP installed.

log:https://drive.google.com/drive/folders/1rjEPjLuptMQCc7bo6anTQyyA546uaTiG?usp=sharing

OhioBob · December 22, 2020

8 hours ago, ra4nd0m said:

I've been testing this mod on1.11 and got logspam with EVE installed. EVE itself without GEP works fine. Logspam starts only with GEP installed.

log:https://drive.google.com/drive/folders/1rjEPjLuptMQCc7bo6anTQyyA546uaTiG?usp=sharing

This mod doesn't support 1.11.

ra4nd0m · December 24, 2020

On 12/22/2020 at 11:52 PM, OhioBob said:

This mod doesn't support 1.11.

So i've tried this mod on 1.9.1 and managed to pinpoint the exact problem of this logspam. It is not incompatible version. The problem is caused by latest version of Scatterer.

Please see:

https://drive.google.com/drive/folders/1rjEPjLuptMQCc7bo6anTQyyA546uaTiG?usp=sharing

OhioBob · December 24, 2020

6 hours ago, ra4nd0m said:

The problem is caused by latest version of Scatterer.

This mod has not been updated to support the new scatterer. There is no timetable for when it will.

PocketBrotector · December 24, 2020

49 minutes ago, OhioBob said:

This mod has not been updated to support the new scatterer. There is no timetable for when it will.

Just to clarify, what is meant by "new scatterer" here? Is that v0.0722 specifically, or some other version range? I don't mean to sound dense, I just want to make sure that I'm not accidentally inviting trouble by mixing potentially incompatible versions of different mods.

OhioBob · December 24, 2020

On 12/24/2020 at 11:41 AM, PocketBrotector said:

Just to clarify, what is meant by "new scatterer" here? Is that v0.0722 specifically, or some other version range?

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.

Edited January 9, 2021 by OhioBob

Aelipse · January 2, 2021

Thank you for this wonderful mod. I have had it installed for a while, but only now have I progressed my career enough to start dipping my toes into it, and I am loving it.

I have a question regarding Taranis, the warmest planet in the game. I have performed some test landings near the lava sea using cheats to see if my ship could withstand the extreme heat, and it seems like there is a script that periodically increases the temperature of the parts on the active vessel. I am still not sure as this is not exactly easy to test, but the heating seems to be directly dependent on the altitude above the sea level. Is that the case? I don't want to be delving into a huge, several hundred years long mission only to have my vessel destroyed by a script I don't understand. Thank you!

Edited January 2, 2021 by Aelipse

OhioBob · January 2, 2021

2 hours ago, Aelipse said:

Thank you for this wonderful mod. I have had it installed for a while, but only now have I progressed my career enough to start dipping my toes into it, and I am loving it.

I have a question regarding Taranis, the warmest planet in the game. I have performed some test landings near the lava sea using cheats to see if my ship could withstand the extreme heat, and it seems like there is a script that periodically increases the temperature of the parts on the active vessel. I am still not sure as this is not exactly easy to test, but the heating seems to be directly dependent on the altitude above the sea level. Is that the case? I don't want to be delving into a huge, several hundred years long mission only to have my vessel destroyed by a script I don't understand. Thank you!

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.

Aelipse · January 2, 2021

1 hour ago, OhioBob said:

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.

Thank you for the quick reply!

It's weird because some of the parts on my vessel should withstand temperatures over 3000 K, and they too exploded after a rather short while. I am using an older version of the game (1.7.3) and the respective version of your mod, and I am not sure if there have been any changes in this particular regard... or perhaps the additional heating is caused by light from Grannus. Either way, I am unable to find a way around it. Shame. I was so attracted by the notion of visiting the burning shores.

OhioBob · January 3, 2021

4 hours ago, Aelipse said:

I am using an older version of the game (1.7.3) and the respective version of your mod

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.

Starhelperdude · January 5, 2021

is there a way to make the orbit of grannus higher around the stock sun so grannus' orbit doesn't overlap with other mods?

OhioBob · January 5, 2021

6 hours ago, Starhelperdude said:

is there a way to make the orbit of grannus higher around the stock sun so grannus' orbit doesn't overlap with other mods?

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
		}
	}
}

Hohmannson · January 8, 2021

unknown.png?width=1068&height=556

Just a GEP appreciation post

kerbnub · January 10, 2021

I've been play a JSNQ career for a while (loving it) and am about ready to add GEP. I'm sure you guys know what you're doing, so I was wondering why the JSNQ version is rescaled to 2.5x instead of 2.7x. Does it fit better that way (was it originally already harder than stock)? Can that scale easily be changed?

OhioBob · January 10, 2021

2 hours ago, kerbnub said:

I've been play a JSNQ career for a while (loving it) and am about ready to add GEP. I'm sure you guys know what you're doing, so I was wondering why the JSNQ version is rescaled to 2.5x instead of 2.7x. Does it fit better that way (was it originally already harder than stock)? Can that scale easily be changed?

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.

Edited January 10, 2021 by OhioBob

OhioBob · January 24, 2021

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.

Edited February 27, 2021 by OhioBob

OhioBob · February 12, 2021

UPDATE

Version 1.2.3

Changelog

Changed starting position & rotation of Nodens and Belisama.
Deleted MyRocksAreBiggerThanYours.dll.
Fixed error in GEP_CommNet.restockblacklist.

See opening post for download link and instructions.

Since the last update (v1.2.2) changed the calendar to have months based on the orbit of Nodens' moon, it makes sense that each month begins at the start of a new lunar cycle. Therefore, the starting positions of Nodens and Belisama in their orbits have been changed so that a new moon occurs on the first day of each month. This also required a change in the initial rotations so that each body keeps the same face pointed toward the other. Also note that the new moon at the start of each new year produces a total solar eclipse (though it's only a partial eclipse when observed from KSC).

Beware that this change could break existing saves. Potential problems include: (1) spacecraft currently on the way to Nodens or Belisama will result in a miss, (2) the date and time of future launch windows will change, and (3) the terrain beneath geosynchronous satellites will change. If you fear any of these problems, then I suggest you do not update until you are sure you can do so safely.

Edited February 13, 2021 by OhioBob

[1.12.5] Grannus Expansion Pack [v1.2.8] [10 May 2022]

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation