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

[Sigma88]

10 hours ago, OHara said:

I added https://github.com/prestja/Kopernicus/issues/19 
but have not set up to compile and test C#, so hope @Sigma88 might still be in position to confirm if this was his original intent, and motivated to make a pull request.

I can't remember for sure, but if my code worked fine and the new code doesn't it could be an indication to that effect.

However if my code was changed it could be because there was an issue with it, so whoever changed it should look how to make the new code work in your use case

 

Multiple star is always a headache and changing stuff while not testing with multiple stars will usually lead to this kind of issues

[R-T-B]

Can I just drop a quick thank you both here OhioBob & Ohara for continuing to produce more properly documented bug reports than anyone else?

I know sometimes my coding style can resemble a bull in a china closet, which is why I am moving more and more to my own branch.  But all the same, I'm pretty sure this bug is nailed down in my latest beta on my thread, if you'd like to test.  Supports 1.9.1 and 1.10.

Oh and OHara, I don't think GCC will compile C# for you (I've never heard of it anyhow).  You'll need mono...  in *nix land C# is really an icky mess.  But that's proprietary languages for you.  Unity uses it though, so what can we do?

I use to dev .net languages on linux, but it was a major PITA and I finally just set up a windows VM.  I know that's not an option for everyone, but if it is for you, consider it.  We could use someone with your coding talent.  I'm not going to pretend I'm fully aware of how Kopernicus works (honestly I'm maybe 25% of the way there), so every little bit helps.

On 7/20/2020 at 3:12 AM, Sigma88 said:

However if my code was changed it could be because there was an issue with it, so whoever changed it should look how to make the new code work in your use case

Yeah, I didn't just change it for fun...  heh.  There were already headaches, not so much with your code but moreso with it not running due to some checks, which I removed, leading us to where we are now.  See: https://github.com/prestja/Kopernicus/issues/3

I finally just removed that whole override in the latest attempt and made a local "GetLocalStar()" function.  I believe that override was unintended or not needed at any rate, as it overrides the standard GetBodyReferencing and isn't used like, anywhere else.

FWIW the rest of your code appears pretty darn solid for multistar, which is great.

Edited July 21, 2020 by R-T-B

[Sigma88]

9 hours ago, R-T-B said:

I finally just removed that whole override in the latest attempt and made a local "GetLocalStar()" function.  I believe that override was unintended or not needed at any rate, as it overrides the standard GetBodyReferencing and isn't used like, anywhere else.

FWIW the rest of your code appears pretty darn solid for multistar, which is great.

my only doubt with that solution is that while the override returns a planet the "GetLocalStar" returns a star

 

however, if the use cases are working properly, then I would assume it's fine

[hemeac]

@OhioBob, have you experienced any severe slowdowns while approaching RAB-58E in either 1.8.1 or 1.9.1?  I had been testing to verify an issue of lag on a planet in MPE (https://github.com/prestja/Kopernicus/issues/26), when on a hunch tried RAB and noticed a similar slowdown on a non-potato PC and in a pretty basic install, stock + Kopernicus (with correct versions installed).  Logs are linked in Github in case you're curious, but @R-T-B is aware of the issue.

[OhioBob]

4 hours ago, hemeac said:

@OhioBob, have you experienced any severe slowdowns while approaching RAB-58E in either 1.8.1 or 1.9.1?  I had been testing to verify an issue of lag on a planet in MPE (https://github.com/prestja/Kopernicus/issues/26), when on a hunch tried RAB and noticed a similar slowdown on a non-potato PC and in a pretty basic install, stock + Kopernicus (with correct versions installed).  Logs are linked in Github in case you're curious, but @R-T-B is aware of the issue.

I haven't observed a problem before but I just tested it and yes, performance drops as soon as I get to within about 70,000 meters of it.  That happens to be the deactivate altitude for the PQS.

[Angelo Kerman]

It works with JNSQ! Yaaaay!

[OhioBob]

GEP Patch

Many of you have undoubtedly experienced a terrain bug while playing GEP or other planet packs that looks like this:

Thanks to @R-T-B, the cause of this has been identified.  I've written a patch for GEP that should fix it.  Just download the following zip file, select the version of KSP that you are currently using, and install the patch as indicated.  If playing KSP v1.10+, no patch is required.

Download GEP Patch

[Oblate Prince]

Does the Grannus primary config work when combined with the JNSQ rescale config?

[theJesuit]

What's the reason for the kerbalism issues with JNSQ or used as a secondary system?  Is it the scaling or another issue?

[OhioBob]

13 hours ago, Oblate Prince said:

Does the Grannus primary config work when combined with the JNSQ rescale config?

No.  GEP_JNSQ requires JNSQ to work, and JNSQ and GEP_Primary are incompatible.

You can install JNSQ + GEP + GEP_JNSQ, which will add GEP to JNSQ as a rescaled secondary system.  But you can't add GEP_Primary to that mix.

And if you install GEP + GEP_Primary + GEP_JNSQ, then GEP_JNSQ does nothing.

If you want GEP as a rescaled primary system, then I suggest installing GEP + GEP_Primary + Rescale.
 

6 hours ago, theJesuit said:

What's the reason for the kerbalism issues with JNSQ or used as a secondary system?  Is it the scaling or another issue?

I don't know what Kerbalism issues you are talking about.
 

Edited October 2, 2020 by OhioBob

[darwinpatrick]

Something very strange is going on with Nodens... take a look at the periapsis value.

Spoiler

Basically, Nodens is small. In map, tracking station, even flight above around 80km. The proper surface slowly fades into existence around 80km and the mini-Nodens is gone past 30km. Needless to say, it's incredibly frustrating. I'm putting a video together on this grand colony mission so I have footage of what exactly happens when vessels hit ghost Nodens (very, very unnerving) if anyone is interested. The video's production may end here unless I can get Nodens to stop being tiny; it's been doing this for, as far as I can tell, since I started this career. (Also, it's hard to tell from the picture, but mini-Nodens's oceans are missing...)

Is this something that anyone has ever encountered? I'll test more stuff in a sandbox but for now I'm just baffled.

[OhioBob]

16 hours ago, darwinpatrick said:

Is this something that anyone has ever encountered? I'll test more stuff in a sandbox but for now I'm just baffled.

I have not seen or heard of anything like that.  I have no idea what could be causing it.

[Maple Kerman]

GEP is compatible with EVE, OPM, and MPE, which is great. However, I have a few questions.

1. GEP_CommNet uses Custom Barnkit to add a Level 4 Tracking Station. However, OPM has its own version of a Level 4 Tracking Station. Does GEP_CommNet override OPM?
    
2. The post states "Orbits are modified as necessary to assure seamless integration." Which orbits are changed, and how so?
    
3. As for EVE support, is GEP incompatible with any visual packs for EVE? (Spectra, SVE, AVP, etc.)

[hemeac]

17 minutes ago, Maple Kerman said:

GEP is compatible with EVE, OPM, and MPE, which is great. However, I have a few questions.

1. GEP_CommNet uses Custom Barnkit to add a Level 4 Tracking Station. However, OPM has its own version of a Level 4 Tracking Station. Does GEP_CommNet override OPM?
    
2. The post states "Orbits are modified as necessary to assure seamless integration." Which orbits are changed, and how so?
    
3. As for EVE support, is GEP incompatible with any visual packs for EVE? (Spectra, SVE, AVP, etc.)

@Maple Kerman,  The GEP commnet patch runs only if OPM is not present; I don't think GEP Secondary modifies any orbits from OPM, but it will bring in a few orbits for the Minor Planets Expansion; Lastly, I am running it alongside AVP and have not had any issues.

[Maple Kerman]

@hemeacAlright, thanks. Do you know which MPE orbits it changes, by any chance?

[OhioBob]

4 hours ago, Maple Kerman said:

1. GEP_CommNet uses Custom Barnkit to add a Level 4 Tracking Station. However, OPM has its own version of a Level 4 Tracking Station. Does GEP_CommNet override OPM?

The OPM and GEP Tracking Stations are identical.  There is coordination between the mods to assure it gets added once and only once.

Quote

The post states "Orbits are modified as necessary to assure seamless integration." Which orbits are changed, and how so?

It depends on how you have the mods installed.  I'm assuming you have the stock solar system with OPM added, and GEP installed as a secondary star system.  Is that correct?  In that case the OPM orbits are not modified at all.  The only MPE body to have its orbit changed is Soden.  If you have some other installation, such as GEP_Primary, then there could be many orbit changes.

Quote

As for EVE support, is GEP incompatible with any visual packs for EVE? (Spectra, SVE, AVP, etc.)

GEP works with SVE (assuming, of course, that you have the stock planets as part of your installation).  I don't know about Spectra and AVP.

[Maple Kerman]

12 hours ago, OhioBob said:

The OPM and GEP Tracking Stations are identical.

Oh, never mind about that, then.

12 hours ago, OhioBob said:

I'm assuming you have the stock solar system with OPM added, and GEP installed as a secondary star system.  Is that correct?

I have the stock system with both OPM and MPE added, nothing else. (I plan to install "secondary" GEP.) I assume Soden's orbit is made smaller due to how far out it goes.

12 hours ago, OhioBob said:

GEP works with SVE

That's all I needed. Thank you!

[OhioBob]

1 hour ago, Maple Kerman said:

I have the stock system with both OPM and MPE added, nothing else. (I plan to install "secondary" GEP.) I assume Soden's orbit is made smaller due to how far out it goes.

Stock + OPM + MPE + GEP (secondary) should work fine.  If left unmodified, Soden's orbit would take it beyond the orbit of Grannus (possibly crossing into Grannus' SOI eventually).  I left Soden's periapsis unchanged but significantly lowered its apoapsis.  Grannus' orbit is also changed when MPE is installed.  The orbit of Grannus was originally designed to accommodate OPM and GPP, not MPE.  With MPE installed, Grannus is moved to more than twice its original distance to accommodate the large orbits of the outer minor bodies.  Soden's was so extreme, however, I changed it to accommodate Grannus.

[Maple Kerman]

@OhioBob That really clears things up, thanks again.

[hemeac]

 @OhioBob, I had found that the sun intensity curves set by GEP (secondary) can leave the MPE planets in complete darkness when coupled with visual mods.  I had created a patch for MPE to extend the sun intensity out a bit further, but keep it from shining on the planets in GEP.  I had posted in the MPE thread a while back, but not sure if it will be adopted.  It was based off your tutorial on light intensity curves in a thread a couple of years ago, so don't think it would be better than what you can come up with, but happy to post it if you would like.

 

Edited October 25, 2020 by hemeac

[OhioBob]

48 minutes ago, hemeac said:

 @OhioBob, I had found that the sun intensity curves set by GEP (secondary) can leave the MPE planets in complete darkness when coupled with visual mods.  I had created a patch for MPE to extend the sun intensity out a bit further, but keep it from shining on the planets in GEP.  I had posted in the MPE thread a while back, but not sure if it will be adopted.  It was based off your tutorial on light intensity curves in a thread a couple of years ago, so don't think it would be better than what you can come up with, but happy to post it if you would like.

Thanks for bringing this to my attention.  I'll have to take a closer look at the intensity curves - there may be other scenarios where adjustment is needed.  Thanks for the offer to share the curve, but since I need to review all the different installation options, it will probably be best to just redo it all myself.

[OrbitalManeuvers]

Hello Ohio, hello Bob, hello all. Just today saw a reference to this planet pack so here I am.  I've installed it as primary with rescale. I took a working JNSQ install and deleted JNSQ/RR, and dropped in this and primary (plus rescale/dimensions/kron) and bingo!  My only issue is shown below ... the runway is a little low. The other two buildings you can see were there from my JNSQ install since I copied all the folders from that, and they were a bit low, too. Is there a way to bump KSC upward a notch? 

Spoiler

 

[OhioBob]

1 hour ago, OrbitalManeuvers said:

Is there a way to bump KSC upward a notch?

I suggest this... 

1.  Find the file GameData/GEP_Primary/Nodens.cfg 

2.  Open the file and scroll to the bottom to where you see this:

Spoiler

		SpaceCenter
		{
			//PQSCity
			latitude = 10.06
			longitude = 28.27
			lodvisibleRangeMult = 6
			repositionRadiusOffset = 3950
			reorientFinalAngle = 241.73
			Material
			{
				nearGrassTexture = GEP/GEP_Textures/PluginData/grass0.dds
				nearGrassTextureOffset = 0,0
				nearGrassTextureScale = 1,1
				nearGrassTiling = 0.08
				farGrassTexture = GEP/GEP_Textures/PluginData/grass0.dds
				farGrassTextureOffset = 0,0
				farGrassTextureScale = 1,1
				farGrassTiling = 0.06
				farGrassBlendDistance = 4000
				grassColor = 0.825,0.725,0.665,0
			}
		}

 

3.  Increase the setting repositionRadiusOffset until the runway is no longer buried.

[OrbitalManeuvers]

31 minutes ago, OhioBob said:

3.  Increase the setting repositionRadiusOffset until the runway is no longer buried.

Awesome, thanks. 3955 did the trick for me.

[Souptime]

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

Oh it just has a tiny SOI nevermind