Jump to content

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


OhioBob

Recommended Posts

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.

Link to comment
Share on other sites

  • 2 weeks later...

@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!

Link to comment
Share on other sites

@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 (m3/s2) = 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 by OhioBob
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by OhioBob
Link to comment
Share on other sites

  • 2 weeks later...

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 by Aelipse
Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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 by OhioBob
Link to comment
Share on other sites

  • 2 weeks later...

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 by OhioBob
Link to comment
Share on other sites

  • 3 weeks later...

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 by OhioBob
Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...