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

[HebaruSan]

17 minutes ago, Maelstrom Vortex said:

Any possibility I could convince someone to give a look at sunAOA, I really think that's what's causing my directable panels to malfunction while all others work normal.

PM me if you want some help setting up a development environment to try it yourself. I'm immersed in this ring stuff at the moment but could spare some time to advise on getting it to compile on your machine.

[Maelstrom Vortex]

Update: Isolated the problem and confirmed it's source as Interstellar Adventure. The old version of IA still loads on 1.2.2, but the light curvatures are obviously not presenting correctly. I will notify the mod administrator. Koppernicus is working normally without the extra stars.

[KerbMav]

22 hours ago, OhioBob said:

I had this same issue once before, where I wanted a thin atmosphere but a black starry nighttime sky.  I tried several things but was never able to figure it out.  No matter what I did, when daylight came the stars disappears and I got a lighted sky.  I eventually gave up and deleted the atmosphere.  Of course that was several versions of Kopernicus ago, so maybe things have changed.  What happens if you try this...

  Reveal hidden contents

@Kopernicus
{
    @Body[Minmus]
    {
        Atmosphere
        {
            lightcolor = 0,0,0,0
            enabled = true
            oxygen = false 

            altitude = 400.0
            atmosphereMolarMass = 0.000019999990016222
            pressureCurve
            {
                key = 0 1
                key = 50 0.5
                key = 400 0
            }
            temperatureSeaLevel = 223.15
            temperatureCurve
            {
                key = 0 223.15
                key = 400 233.15
            }
        }    
    }
}

 

Can't really tell, set the atmosphere below the cloud level - still getting some shining on the horizon, but all in all it looks kinda neat actually.

Edited August 7, 2017 by KerbMav

[HebaruSan]

On 10/15/2016 at 0:00 PM, OhioBob said:

I'm assisting on the development of a mod and we've run into trouble with a planetary ring and moonlet.  We have a ring system that is inclined about 30 degrees to the planet's equator and we want to have a moonlet embedded in a gap in the rings.  The problem we're having is that we can't seem to be able to lock down the orientation of the rings.  The line of nodes seem to randomly change and I haven't been able to identify any particular cause or pattern.  For example, I'll load up the game and use KittopiaTech to determine what the ascending node of the moonlet must be to match the plane of the rings.  I'll exit, edit the moonlet's cfg, restart the game, and the planes are nowhere near each other.  Using the direction of the sun for reference, it appears that the moonlet's orbit is correct, but the line of nodes of the ring plane has shifted from what it was previously.  I can never get the rings and moonlet coplanar.  Does anybody know how to fix this problem?  Is there an "ascendingNode" parameter or something similar for rings that will lock down their orientation?

This is really bizarre. There are two rotation objects available, ring.transform.rotation and ring.transform.localRotation. The former is in terms of world coordinates, and the latter is relative to the parent transform, but otherwise they represent the same operation. So naturally if you choose one to set every update, localRotation will result in a ring with a rotating LAN, whereas rotation will give a stationary ring. (This is the difference between lockRotation=false and lockRotation=true in the released versions of Kopernicus.)

However, if you allow some time to elapse and quit normally (as opposed to force killing KSP to avoid updating the save), then everything changes somehow. If you're setting ring.transform.rotation, then the ring will switch orientation on load (but never again within the same session), even if you're setting it to the exact same value as in the previous session. But If you instead set ring.transform.localRotation, then the orientation at load will be the same as it was when you quit last time (but continue rotating).

So, setting a constant rotation in world coordinates gives different results in different sessions. This seems to point to the conclusion that world coordinates are not absolute! Rather than defining a persistent coordinate system in terms of a known reference direction (in effect, oriented toward a particular distant constellation), the definitions of the +X and +Z vectors seem to be set at startup based on ??? and then the whole solar system is laid out with respect to those (random?) vectors.

Can anyone with more experience with KSP's coordinate systems comment on what could explain this? Am I misinterpreting something? Is there in fact a reliable/persistent reference direction that's being masked somehow? If not, any idea how it determines how the world will be rotated at startup, so we can define a persistent plane for rings?

[HafCoJoe]

Hm, I recall there being an old planet pack with a planet that spun so fast you couldn't land at the equator - does anymore remember the name of the planet or planet pack?

[NeoFatalis]

28 minutes ago, Avera9eJoe said:

Hm, I recall there being an old planet pack with a planet that spun so fast you couldn't land at the equator - does anymore remember the name of the planet or planet pack?

Oh I know what your'e talking about, hmm... maybe Kerbol plus?

 

[Mrcarrot]

On 8/10/2017 at 0:20 PM, Avera9eJoe said:

Hm, I recall there being an old planet pack with a planet that spun so fast you couldn't land at the equator - does anymore remember the name of the planet or planet pack?

PlanetFactory. Inaccessable. You might be thinking of the Sentar Expansion, though, because that is a remake of PlanetFactory for Kopernicus. (PlanetFactory was last released for 0.23 and is totally unrelated to Kopernicus.)

Edited August 13, 2017 by Mrcarrot

[HebaruSan]

On 10/15/2016 at 0:00 PM, OhioBob said:

I'm assisting on the development of a mod and we've run into trouble with a planetary ring and moonlet.  We have a ring system that is inclined about 30 degrees to the planet's equator and we want to have a moonlet embedded in a gap in the rings.  The problem we're having is that we can't seem to be able to lock down the orientation of the rings.  The line of nodes seem to randomly change and I haven't been able to identify any particular cause or pattern.  For example, I'll load up the game and use KittopiaTech to determine what the ascending node of the moonlet must be to match the plane of the rings.  I'll exit, edit the moonlet's cfg, restart the game, and the planes are nowhere near each other.  Using the direction of the sun for reference, it appears that the moonlet's orbit is correct, but the line of nodes of the ring plane has shifted from what it was previously.  I can never get the rings and moonlet coplanar.  Does anybody know how to fix this problem?  Is there an "ascendingNode" parameter or something similar for rings that will lock down their orientation?

I've submitted a pull request to address this and add a longitudeOfAscendingNode property for rings:

https://github.com/Kopernicus/Kopernicus/pull/204

My solution to the question about absolute coordinates was to set transform.localRotation and subtract off the parent body's rotation based on its rotation period and the current UT. The folks that I knew had encountered this issue are already tagged on Github, but if anyone else is interested in having a look, more eyes on the code would be appreciated.

[OhioBob]

Thanks, @HebaruSan.  It just makes sense to me that rings should have a LAN property just like moons.  Hopefully Kopernicus will add this in a future release.

[Poodmund]

2 hours ago, OhioBob said:

Thanks, @HebaruSan.  It just makes sense to me that rings should have a LAN property just like moons.  Hopefully Kopernicus will add this in a future release.

Thomas P has merged the changes into the master branch so you can test it out right away if you want to.

[Syczek]

Help i have little problem : using galactic neighborhood and having many stars yet solar panel in flight mode facing galactic core instead kerbin,i searched trough forums and still trying figure out how to fix it .

[Gilph]

Hi, I also have a solar panel issue.  I just started a GPP career in 1.3 and am using the OX fixed panels.  I was in orbit around Gael and had a panel pointing straight up at Ciro (like it was noon on the surface and Ciro is directly overhead).  The power flow numbers were correct, (close to 100%) but the panel status said "blocked by Gael". While I didn't confirm it at the time, it may be trying to align to Grannus.  In any case, it was not tracking at all to Ciro.

The short term workaround for me is use the large and small OX panels on these smaller ships, but that will not be sustainable.  I don't think I'm using anything that modifies the panels, it's a pretty basic GPP only install.  I use Near Future Electrical, so I'll see if they used anything to modify the stock panels and delete if they did.

Thanks

Edited August 17, 2017 by Gilph
typos

[JadeOfMaar]

On 8/16/2017 at 5:22 AM, Syczek said:

Help i have little problem : 

I think the devs here are well aware of this problem.  

A fix may take a good long time. Kopernicus is a huge mod and the modders have their lives.

12 minutes ago, Gilph said:

Hi, I also have a solar panel issue.  I just started a GPP career in 1.3 and am using the OX fixed panels.  I was in orbit around Gael and had a panel pointing straight up at Ciro (like it was noon on the surface and Ciro is directly overhead).  The power flow numbers were correct, (close to 100%) but the panel status said "blocked by Gael". While I didn't confirm it at the time, it may be trying to align to Grannus.  In any case, it was not tracking at all to Ciro.

The short term workaround for me is use the large and small OX panels on these smaller ships, but that will not be sustainable.  I don't think I'm using anything that modifies the panels, it's a pretty basic GPP only install.  I use Near Future Electrical, so I'll see if they used anything to modify the stock panels and delete if they did.

Thanks

Near Future Electrical adds reactors and their custom mechanic, and has no business with solar. Near Future Solar is no more than a parts pack. As I mention above, the solar panel problem is purely a Kopernicus thing.

[Thomas P.]

I released Kopernicus 1.3.0-5 / backport 1.2.2-10, you can read the changelog on github (where you find the download too). It contains some pretty neat features for stars and rings.

https://github.com/Kopernicus/Kopernicus/releases/tag/release-1.3.0-5

[Galileo]

Well! Thanks @Thomas P.!

Edited August 17, 2017 by Galileo

[Galileo]

Is there documentation on the syntax for these thick rings? or the new intensity for starlight?

Edited August 17, 2017 by Galileo

[Poodmund]

I'd ping @HebaruSan if you're interested in the new Ring syntax.

Judging by the code I'd say the following properties can be added under the Ring node:

thickness = (float) - Where value equals distance between the top and bottom faces in milliradii

tiles = (float) = Where value equals number of times the texture should be tiled around the cylinder. If zero, use the old behavior of sampling a thin diagonal strip from (0,0) to (1,1).

longitudeOfAscendingNode = (float) - Where the angle between the absolute reference direction and the ascending node. Works just like the corresponding property on celestial bodies.

EDIT: A quick note on the above, I seemed to have to give the ring a LAN of 180 degrees to get the ring to align with the rotational plane of the body if using EVE's 'offset' value to incline the bodies texture.

Edited August 17, 2017 by Poodmund

[OhioBob]

And also is there some documentation on the syntax for starlight intensity curves?

[Gordon Dry]

Just to mention (as seen in so many other mods) that still MM 2.8.0 is inside the release .zip ...

Sorry I couldn't resist but I become overwhelmed by fresh releases with outdated dependencies inside.

[Galileo]

Just now, Gordon Dry said:

Just to mention (as seen in so many other mods) that still MM 2.8.0 is inside the release .zip ...

Sorry I couldn't resist but I become overwhelmed by fresh releases with outdated dependencies inside.

Its not a huge hassle to replace it or If you have already 2.8.1 in your gamedata folder, its as easy as not copying 2.8.0 from kopernicus. 

[Poodmund]

Thank you for the latest changes to Kopernicus to all those involved, we can now have systems like this:  

A quick note on the above, I seemed to have to give the ring a LAN of 180 degrees to get the ring to align with the rotational plane of the body if using EVE's 'offset' value to incline the bodies texture.

[Thomas P.]

1 hour ago, OhioBob said:

And also is there some documentation on the syntax for starlight intensity curves?

Instead of writing "intensity = <value>" in the Lights node, you can now write something like this

IntensityCurve // also: ScaledIntensityCurve, IVAIntensityCurve
{
    key = <distance from star> <intensity at distance>
    key = <other distance from star> <intensity at other distance>
}

intensity = value will still work, but the curves will overwrite the fixed values.

[HebaruSan]

2 hours ago, Galileo said:

Is there documentation on the syntax for these thick rings?

I've tried to summarize the ring settings here:

https://github.com/Kopernicus/Kopernicus/wiki/Rings

It's a wiki, so please correct any errors you notice. I'll add a few links from other appropriate wiki pages.

[OhioBob]

32 minutes ago, Thomas P. said:

Instead of writing "intensity = <value>" in the Lights node, you can now write something like this

IntensityCurve // also: ScaledIntensityCurve, IVAIntensityCurve
{
    key = <distance from star> <intensity at distance>
    key = <other distance from star> <intensity at other distance>
}

intensity = value will still work, but the curves will overwrite the fixed values.

Thanks, that's helpful.  Intensity is just a value between 0 and 1, right?  What units is distance in?

[HafCoJoe]

Congrats on the release! I noticed that you have an outdated version of ModuleManager in the zip though?