[1.8.1-1] [PLEASE FORK ME] Kopernicus & KittopiaTech

[Mrcarrot]

On 10/3/2017 at 9:39 PM, MrChumley said:

It looks like the popup is from kopernicus just letting you know it is unable to load.

Your planetary system works, it just isn't at 100%. @Thomas P. how about a feature that reverts the system if Kopernicus doesn't load it properly(if this already exists, sorry for asking)

[Thomas P.]

Just now, Mrcarrot said:

Your planetary system works, it just isn't at 100%. @Thomas P. how about a feature that reverts the system if Kopernicus doesn't load it properly(if this already exists, sorry for asking)

Applying the new system is the last step in the loading process, and it is almost completely failsafe. If that popup comes up, the unmodified stock system got spawned instead of the failing Kopernicus system.

[Mrcarrot]

Just now, Thomas P. said:

Applying the new system is the last step in the loading process, and it is almost completely failsafe. If that popup comes up, the unmodified stock system got spawned instead of the failing Kopernicus system.

When I use @GregroxMun's Kerbfleet Planets with homeworld Kerbulus, I always get that popup, and I'm still on Kerbulus. Just what I was using for reference, if he wants to fix that, cool, if not, less cool(but still fine)

[Thomas P.]

1 minute ago, Mrcarrot said:

When I use @GregroxMun's Kerbfleet Planets with homeworld Kerbulus, I always get that popup, and I'm still on Kerbulus. Just what I was using for reference, if he wants to fix that, cool, if not, less cool(but still fine)

Hmm, actually, there is a way that this could happen: An issue in the post spawn fixer, or a missing reference body in PostSpawnOrbit. If that happens, the system will be active (still I wouldn't recommend loading anything with it). However, at that point, reverting isn't possible anymore.

But in most of the cases, the system should stay at it's original state.

[Thomas P.]

And we have the first bugfix release. 1.3.1-2 is out, and it changes how Kopernicus handles lens flares, since that got changed in 1.3.1.

Have even more fun (or something like that.. dunno).

[1990eam]

Where can I get the 1.3 version of this mod? I'm running 1.3 since most of the mods I use haven't been updated to 1.3.1 yet.

Or will this work with 1.3?

Edited October 7, 2017 by 1990eam

[Sigma88]

36 minutes ago, 1990eam said:

Where can I get the 1.3 version of this mod? I'm running 1.3 since most of the mods I use haven't been updated to 1.3.1 yet.

Or will this work with 1.3?

on the github release page you can find all versions, just look for those named    1.3.0-x

latest one was 1.3.0-8

[TheProtagonists]

So... If the SOI of planets and moons are calculated through mass and radius (For all the planet pack mods I can see they do not separately define SOI for anything that isn't a star)

Is the only way to make sure multiple moons' SOI doesn't overlap each other trial and error?

[OhioBob]

14 hours ago, TheProtagonists said:

So... If the SOI of planets and moons are calculated through mass and radius (For all the planet pack mods I can see they do not separately define SOI for anything that isn't a star)

Is the only way to make sure multiple moons' SOI doesn't overlap each other trial and error?

You don't have to do it by trial and error, you can compute the SOI radii.  The formula is,

r_SOI = a * (m / M)^0.4

where r_SOI is the SOI radius, a is semimajor axis, m is the mass of the secondary body (moon), and M is the mass of the primary body (planet).

If you don't know the masses, you can compute them using one of the following formulas,

m = μ / 6.67408E-11

m = g * r² * 9.80665 / 6.67408E-11

where  μ is gravitational parameter, g is surface gravity (in gees), and r is the body's radius (in meters).

Which of the last two equations you use depends on what information you're given in the body's config file.  If given gravParameter use the first; if given geeASL use the second.

If you don't like the computed SOI, you can always assign a custom SOI radius using the sphereOfInfluence parameter.
 

Edited October 9, 2017 by OhioBob

[1990eam]

When I install Kopernicus the game freezes upon launch. Unfortunately it doesn't create a crash log. Any idea why this can happen? I've tried all the different versions for KSP 1.3.0 .

[Galileo]

1 hour ago, 1990eam said:

When I install Kopernicus the game freezes upon launch. Unfortunately it doesn't create a crash log. Any idea why this can happen? I've tried all the different versions for KSP 1.3.0 .

could be anything, but we can't know unless you give us the proper information required for troubleshooting. Click the link HERE to find instructions on how to do a proper Kopernicus issue report.

Edited October 9, 2017 by Galileo

[Sigma88]

3 hours ago, TheProtagonists said:

So... If the SOI of planets and moons are calculated through mass and radius (For all the planet pack mods I can see they do not separately define SOI for anything that isn't a star)

Is the only way to make sure multiple moons' SOI doesn't overlap each other trial and error?

On first run kopernicus needs to create cache files for all planets. That takes time, so you might just need to wait for it to be completed.

It's unlikely that you don't have logs, look at the link galileo posted to see where you can find them.

If really you have no logs it means that the issue is deeper than Kopernicus.

[TheProtagonists]

I see... I'm just trying to find a way to better visualize SOIs since looking into the logs only gives a abstract numbers

The best way to visualize that I can think of is editing ships onto the edge of the SOIs

[Sigma88]

55 minutes ago, TheProtagonists said:

I see... I'm just trying to find a way to better visualize SOIs since looking into the logs only gives a abstract numbers

The best way to visualize that I can think of is editing ships onto the edge of the SOIs

what I do is use HyperEdit to put a moon in orbit around the body at the distance of the SOI

it's easier than using a craft

[OhioBob]

14 hours ago, TheProtagonists said:

Is the only way to make sure multiple moons' SOI doesn't overlap each other trial and error?

You can always check it mathematically.  One simple check you can do is take the periapsis distance of the outer moon and subtract from it the apoasis distance on the inner moon, then from that subtract to two SOI radii, and that will give you the worst case separation between the edges of the SOI.

SOI separation = Pe₂ - Ap₁ - SOI₁ - SOI₂

This is the theoretical worst case because it assumes the orbits are in the same plane and that the inner moon's apoapsis aligns with the outer moon's periapsis (i.e. the longitudes of periapsis differ by 180 degrees).  In reality this is probably not the case, which means the real minimum separation is going to be greater then this.  But if this calculation shows that the SOI do not overlap (i.e. separation > 0), then you know you are good to go.

My experience is that if you give the moons realistic orbits, their SOI are unlikely to overlap.  If the SOI do overlap, it would probably be best to move the orbits farther apart.  If two moons come so close to one another that the SOI overlap, then I suspect that in real life they would probably have unstable orbits.

[Thomas P.]

3 hours ago, TheProtagonists said:

I see... I'm just trying to find a way to better visualize SOIs since looking into the logs only gives a abstract numbers

The best way to visualize that I can think of is editing ships onto the edge of the SOIs

Add this to your Body node:

Debug
{
    showSOI = true
}

-----------------------------------------------------------------------

In other news:

For the past days @Sigma88 @GregroxMun @Gameslinx and myself have been working on setting up an official Kopernicus Discord Server. It is meant to be some kind of central hub for Kopernicus planet makers to exchange ideas, post pictures of their WIP stuff and also learn new things. We also want to move the development chat that is currently on IRC to Discord. One of the main reasons for creating this server is, that the entry barrier for Discord is way lower than for IRC, and real time chat is often better for supporting and teaching new features than a forum thread. And it is easier to stay up-to-date with the backlog, because you don't have to setup stuff like an IRC Bouncer if you don't want to miss anything.

Anyways, I am bad at describing things. So, if you are interested, just check it out! The Invite link is: https://discord.gg/Q2bnQ7N

Edited October 9, 2017 by Thomas P.

[Aneris]

While trying to use kopernicus I repeatedly run into an error on launch that "Kopernicus was not able to load the custom planetary system due to an exception in the loading process" while used the Alien Space Programs mod, but only while trying to play as the moons of Jool (Laythe and Tylo). I do not know how to share the logs but the end of the log has the following error repeated with different numbers at the beginning:

[EXC 12:21:34.008] NullReferenceException: Object reference not set to an instance of an object
    Kopernicus.Components.KopernicusStar.LateUpdate ()

 

What am I doing wrong and how can I fix it?

[Sigma88]

1 hour ago, Aneris said:

While trying to use kopernicus I repeatedly run into an error on launch that "Kopernicus was not able to load the custom planetary system due to an exception in the loading process" while used the Alien Space Programs mod, but only while trying to play as the moons of Jool (Laythe and Tylo). I do not know how to share the logs but the end of the log has the following error repeated with different numbers at the beginning:

[EXC 12:21:34.008] NullReferenceException: Object reference not set to an instance of an object
    Kopernicus.Components.KopernicusStar.LateUpdate ()

 

What am I doing wrong and how can I fix it?

click on the nyan cat in my sig for info on which files we need to debug an issue

[coyotesfrontier]

Hello all, I'm working on a set of configs which would allow KillAshley's New Horizons to be used with the stock system, and was wondering how I could disable the configs which move the stock planets. I don't want to delete the configs directly (or change anything in the NH folder), and am stumped on how to accomplish this.

[Walesdark]

Laythe PQS height map affecting map view of planet but not actual surface. Help?

I've made an all-water planet in ksp, the surface is completely flat when landed on but Laythe's height map was still showing in map view even though ive disabled all PQS mods (Laythe was template) Help please?

View post on imgur.com

">View post on imgur.com">Album

View post on imgur.com

will appear when post is submitted

[OhioBob]

@Walesdark, try deleting the cache, i.e. the .bin file created by Kopernicus.  Deleting it will force Kopernicus to create a new one.  I'm not certain that's your problem, but it's a good place to start.  If your planet cfg doesn't specify the cache file location, you will find it in the folder Kopernicus/Cache.
 

Edited October 22, 2017 by OhioBob

[Walesdark]

@OhioBob Thanks it worked like a charm

[OhioBob]

3 hours ago, Walesdark said:

@OhioBob Thanks it worked like a charm

I suspect what happened is the old cache file was created when your planet was still using Laythe's old textures.  Anytime you do something that changes the shape of a body (heightmap or PQSmod changes), you should delete the cache and let Kopernicus rebuild it.

[OhioBob]

@Thomas P., @Sigma88, I just reported this as an issue on GitHub, but I thought I'd post it here as well...

I don't think IntensityCurve is working as intended, or at least not as I understand it. I recently tried an experiment in which I used different values for IntensityCurve and ScaledIntensityCurve, in the hope that I could create different lighting conditions in map/tracking station mode versus flight mode. What I found is that the lighting in all modes is currently being controlled by ScaledIntensityCurve. From what I could determine, IntensityCurve currently doesn't do anything.

 

Edited October 22, 2017 by OhioBob

[OhioBob]

@Thomas P., @Sigma88, here's something else I want to run by you guys regarding sunlight intensity curves.

As I understand it, IntensityCurve controls the intensity in flight mode, i.e. the lighting on vessels and nearby celestial bodies.  ScaledIntensityCurve controls the intensity in scaled space, i.e. map mode and tracking station.  Is that correct?

What I'm uncertain about, and what I was trying to test, is what happens in flight mode when moving away from a celestial body and transitioning from a PQS rendered surface to scaled space, or vice versa.  If IntensityCurve and ScaledIntensityCurve have different values, will we see a change in light intensity when moving through that transition?  That's when I discovered the bug that I reported in my last post (ScaledIntensityCurve is currently used in both flight and map/tracking station modes, while IntensityCurve apparently does nothing).

Although I wasn't able to complete my test (because of the bug), it did get me thinking about something.  Perhaps it would be more useful to have intensity curves for each game mode, rather than distinguishing between scaled space and not scaled space.  I don't know if such a thing is possible to do, but perhaps there could be curves like this,

• FlightModeIntensityCurve (both near and far conditions)
• IVAIntensityCurve
• MapModeIntensityCurve
• TrackingStationIntensityCurve

For instance, I might want to have Flight, IVA, and Map modes render sunlight intensity realistically, i.e. decreasing with increasing distance from the sun.  But I might want to show all the bodies in the Tracking Station with the same bright illumination.  By differentiating all those modes, it would provide greater flexibility.