[Kopernicus] Interstellar Consortium

[Pkmniako]

Welcome to the dev page of "Interstellar Consortium", a collection of ideas and agreements regarding the position of stars in KSP Modding

This has the goal of making star planet packs compatible with each other with a simple patch (or no patch at all) at all time without any major problems what-so-ever.

Interstellar Consortium (Github) - Explanation of the Plugin

Link to the decided stars positions spread sheet 

Stellar Viewer Github  & Stellar Viewer

 

The Original Problem 
KSP wasn't designed to host star mods at all and it has multiple problems:

• Just until recently, if you wanted static stars (Not moving stars a.k.a. non colliding stars) you had to create a new central body. This causes a lot of problems with compatiblity and float point errors.
• Planet packs that had their stars orbiting Kerbol/Sun, could have their SOIs (Sphere of Influences) collide and cause some problems if you wanted to go interstellar
• Light of Kerbol/Sun is infinite, so it lights up every planet in the whole game regardless of distance

Most of the problems can be fixed now, like the infinite light problem. And this is where Interstellar Consortium comes into play

 

Interstellar Consortium
Interstellar Consortium will be a series of small patches or decisions between modders to fix these problems and provide a stable interstellar experience by not having a central body put neither have stars moving.

For this, there will be a map describing the position and SOIs of almost every star in KSP modding and a new unit of measure for interstellar distances.

In the technical part, the stars will still be orbiting Kerbol/Sun and won't require important patches, but will be static to avoid collisions by changing the orbital period of these.

 

The Unit and the Map
The new unit for interstellar travel was decided upon looking at an optimal distance at which KSP will still hold up without major glitches.

The unit will be called/shortened ki (Kerbal Interstellar or something like that) and will equal 1e+13m which is close to 0.1% of real distances compared to real life and 1% of what it should be in KSP scale

This was decided for gameplay balancing (Interstellar travel takes time and making these distances longer could be damaging), some realism (Still far enough to feel as a far away target where to go in the future) and glitch-avoiding (Greater distances can cause float point errors and make returning to the home world bad)

 

The map itself is very simple: A central point to consider it the "center of the galaxy" and Kerbol/Sun but with some requirements for the stars so to make everything compatible:

• The minimun distance recommended between two stars should shall be 2 ki - A bit short of what Proxima's distance would be with this unit. 
• The max SOI radius should be 1.2 ki - With this, no SOIs will collide and will avoid some major glitches and gameplay flaws
• The recommended SOI for Main Secuence Stars should be 0.8 ki - This part is entirely albitrary and it's just a recommendation.
• From a star, the closest stellar companion has to be further than its SOI
• No star should go farther than 15 ki from the central point in the plane of the "galaxy" and no farther than 4 ki in the normal axis
• Kerbol/Sun will be at coordinates (10,0,0), being X and Y in the plane of the "galaxy" and Z being up and down - Leads to a feeling of lonliness on the outside and a feeling of crowdness towards the inside
• Star Clusters (Looking at you Dawn from TWB) can have their own stars as close from themselves as the author wants, but has to ensure no star of those are closer than the minimun distance with a external star
• Multiple Star Systems count as a single star system 

The current map has enough space to host 80 to 100 stars which is already a lot and should last for a long time before require of another galaxy or widening of the current one

 

Claming of spaces
Of course if we dont decide on the places the stars are, this whole consortium wouldnt make any sense.

For that, I've created a small sheet on google with a top-down and side views of the whole map/galaxy
(At the moment it doesnt provide the oribit output which will be the actual "orbits" of the stars for the packs, but I'm doing the math)

To claim a part of the map just comment with the coordinates (X,Y, Z) you would like your star to be and make sure to follow the rules previously mentioned.

And if you want to claim more than 2 systems, please don't claim all to be very close to Kerbin/Sun, that would be very sad for all of us and could damage some planet mods. (Higher class stars like F, A, B... could be nice to have a bit more space out to preserve a bit of realism regadring stellar class proportions)

Also, I'm not the only one that would judge the claims. This has to be a consortium after all, a decision made by all of us.

To put your star in the correct place, just put its period at a very high number (9e+50 is a good number) and put as the orbital parameters the ones calculated in the spreadsheet (Todo)

 

System Modify Mods
A lot of planet mods center around changing the stock system to a brand new one.

These changed systems could also serve as a different start point in the map, moving the rest of the stars accordingly to make the effect succesful.

This would mean that, for example, you could start in the GPP system but the map wouldnt change. Kerbol/Sun would still be in the same spot and his neightbor stars would still be the same

This would require the IC mod part to bundle the Stock System cloning data and have the System Modify mods to move every star to the correct locations. (This could be eased with a proper orbit calculator or a custom plugin to ease things)

 

Who are you to say these things
As a disclaimer, I have done a star system of my own and have talked with different planet modders about this and we came to the comclusion that this would be a very good fix to all compatibility issues and at the same time be fun to explore (It's Kerbal Space Program after all, it's meant for rockets and spaceflight)

For the moment, I'm the only contributor to the spread sheet and mod aspect (To be done), but I have talked, again, with people about this and they might come on-board to help with the organization of this map.

 

Participant Planet Packs

• The Worlds Beyond
• Alternis Kerbol Rekerjiggered
• Seven Worlds of SLIPPIST-1
• Whirligig World
• Rocheworld
• Event Horizon
• Galileo Planet Pack
• Gameslinx Planet Overhaul
• Before / After Kerbin
• Other Worlds Reboot

 

Hope you liked the idea, the read, and the english mistakes I probably have done
   - Niako

Edited January 12, 2019 by Pkmniako

[CobaltWolf]

first (this sounds insane in a good way)

Edited August 9, 2018 by CobaltWolf

[Poodmund]

Always nice to see community driven, collaborative frameworks put into place. Good luck with you efforts, Niako.

[GrandProtectorDark]

Hmmm This sounds quite interesting. I'm definitely gonna give it some thought.

[nilslorand]

While I'm not a modder myself, I'm sure projects like this will only help modders in the future

[Elowiny]

Wonderful idea. I hope it bears fruit.

[Zarbon44]

someday I might make my lazy self make a Darwin system mod, and I'll shall join you. 

[GrandProtectorDark]

Community Resources Pack

Community Tech Tree

Community Category Kit

Community Star map

Edited August 10, 2018 by GrandProtectorDark

[FreeThinker]

@Pkmniako

For obvious reasons I think 1e+13m  distance is much to short, therefore I would suggest adding the ability to rescale the distances between the stars using a MM script similar to

That way, it would allow players that are looking for a more challenging or realistic gameplay experience, able to scale up the distances between star systems and planets

Edited August 9, 2018 by FreeThinker

[Pkmniako]

13 minutes ago, FreeThinker said:

@Pkmniako

I think it would be a good idea to support  for

That way, it would allow players that like to have more of a challenging or more realistic play experience to scale up the distances between star systems and planets

Should be done already. Only thing to make sure is that the static orbit must be set before Sigma Dimensions multiplies the semimajor axis of every orbit

[FreeThinker]

1 minute ago, Pkmniako said:

Should be done already. Only thing to make sure is that the static orbit must be set before Sigma Dimensions multiplies the semimajor axis of every orbit

Great, but I just noticed Sigma Dimensions is no longer available. I believe there were some compatibility issues with the last KSP release but perhaps @Sigma can clarify on this better then I.

[Benjamin Kerman]

@FreeThinker and @Pkmniako:

I am not sigma, so I can't speak for him, but what I think is going on is that he has grown tired of updating the KSPF threads. (From a status update)

Quote

don't worry, I'm not stopping with the development of my mods

I just decided to not update the threads for my mods any longer because it has become a chore that brings very little pros and it isn't worth the free-time investment

you can keep following my mods on github / discord and I am still interested in comments from people using my mods so feel free to comment as much as you want 

His mods are still being updated on GitHub, v.0.10.1 of Sigma Dimensions is compatible with KSP v.1.4.3 and Kopernicus v.1.4.3-1. 

Good luck to you with this project @Pkmniako!

EDIT: Here's the release page for Sigma Dimensions. https://github.com/Sigma88/Sigma-Dimensions/releases

Edited August 9, 2018 by Benjamin Kerman

[Pkmniako]

1 minute ago, Benjamin Kerman said:

I am not sigma, so I can't speak for him, but what I think is going on is that he has grown tired of updating the KSPF threads. (From a status update)

His mods are still being updated on GitHub, v.0.10.1 of Sigma Dimensions is compatible with KSP v.1.4.3 and Kopernicus v.1.4.3-1. 

Good luck to you with this project @Pkmniako!

Yeah, I've been following Sigma's mods evolution on github for a time.

Also, thank you, but I think it would be better to say good luck to everyone as this is for the community.

[GrandProtectorDark]

 

Quote

r/kerbalspaceprogram Discord
Niako  9.8.2018
@GPD Blackhole&Wormhole Powered Claim a spot already

Because you asked me so Nicely.

Event Horizon planet pack.
Main "Star" (actually black hole) is Murph (MUUUUUUURPH)
Coords:
                 x: -12.0,
                 y: 2.4,
                 z: 3.0
(Assuming I understand the map right, this should be somewhere near the galaxy center object)
(May change the exact location later but for now there at least some coords)

Edited August 10, 2018 by GrandProtectorDark

[Sigma88]

On 8/9/2018 at 8:41 PM, FreeThinker said:

Great, but I just noticed Sigma Dimensions is no longer available. I believe there were some compatibility issues with the last KSP release but perhaps @Sigma can clarify on this better then I.

 

On 8/9/2018 at 8:53 PM, Benjamin Kerman said:

@FreeThinker and @Pkmniako:

I am not sigma, so I can't speak for him, but what I think is going on is that he has grown tired of updating the KSPF threads. (From a status update)

His mods are still being updated on GitHub, v.0.10.1 of Sigma Dimensions is compatible with KSP v.1.4.3 and Kopernicus v.1.4.3-1. 

Good luck to you with this project @Pkmniako!

EDIT: Here's the release page for Sigma Dimensions. https://github.com/Sigma88/Sigma-Dimensions/releases

 

Like benjamin said, SD has not been abandoned yet, however I didn't have time to test the mod in the last release of KSP so it might have some problems there. it *should* work fine with KSP 1.4.3

[Pkmniako]

Some advancments with the plugin part of things:

@Thomas P. had the idea of introducing a new ID for planets called UBIs (Universal Body Identificators). This already allows for a feature where crafts will stay in the correct planets if you decide to change home system. It will hopefully also be implemented in other mods like scatterer, EVE, DOE... for full mod compatibility

And in other news, Home System change is also progressing. We have discovered that changing the Template of the world Kerbin (Always the Home system) will copy the Template planet to it, pretty much changing the home world completly.

Kerbin after having Duna being set as the Template, 2018, colorized

[Zarbon44]

May i please reserve:
X: 1.8
Y: -11.7
Z: 2.5
The star is called Darwin (might be a Binary) F-class star.

Edited October 14, 2018 by Zarbon44

[Pkmniako]

The plugin part of IC is almost finished. Home switching works incredibly well and the Spheres of Influence work as expected.

We have tested this with a non-home-switching pack and worked. Now its time to do the same with home-switching packs and overall test more edge cases where there could be problems. (again props to Thomas for coding the plugin)

Also, the orbital propieties on the spread sheet were off for everything with a x < 0. This has been updated.

[KSPFanatic102]

Nice idea, looking forward to seeing it finished.

Edited October 30, 2018 by KSPFanatic102

[Jesusthebird]

The reminds me of sigmas galactic neighborhood mod. I welcome this full heart..tho my ram wont lol

[AstralWither]

can I have my stars in the halo (if i ever create stars)?

heres a wikipedia article about the halo:https://en.wikipedia.org/wiki/Galactic_halo

[AstralWither]

cantydeletethispostignorethis

Edited November 10, 2018 by AstralWither

[Thomas P.]

Hello,

as you might know, in the past weeks and months @Pkmniako and myself have been working on creating a plugin for Interstellar Consortium.
At first this plugin was supposed to be a bare orbit calculator, that transforms a stars position into an orbit the star has in-game.
But now, after some experiments and various changes merged into Kopernicus itself to support our usecases, the plugin is ready for a
first release and quite powerful.

The basic goals of Interstellar Consortium are the following:

• Allow for a static star map
• Seamless integrate planet packs with minimal mod-dev interaction
• Allow users to install multiple planet/star packs with little disruption

Interstellar Positioning
The plugin is able to calculate static orbits for the stars based on their position. The position value is relative to the center of
the universe, so as per the spreadsheet from @Pkmniako the stock sun is located at 10,0,0. You define the position like this:

Body
{
    name = My Star
    InterstellarConsortium
    {
        position = 20, 0, 0
    }
}

The orbits the plugin generates are static (i.e. have a very high orbital period so they don't move), and have invisible orbit lines.
That way it looks like you really have a star cluster / galaxy and not multiple stars orbiting another star at the center of the universe.
The automatically generated orbits completely replace most of the contents from the Kopernicus Orbit node, which means that your star
can work in standalone mode and together with IC without additional ModuleManager magic.

If you are not satisfied with the automatically generated orbits, you have the ability to adjust them manually using a Orbit node inside
of the InterstellarConsortium node. It's contents are applied after the autogenerated orbit was calculated.

Since stars in IC might have different SOIs than in standalone, the InterstellarConsortium node includes an SOI parameter that you can
use. Unlike the builtin sphereOfInfluence it isn't specified in meters but in KI, the custom distance unit the spreadsheet uses.

Homeworld Switching
The nature of IC, and the fact that we already wanted to write a plugin for the orbit calculations anyway, made it hard to not explore the
possibility of being able to dynamically set your starting point to a different planet / star system. In a recent Kopernicus release we
added the possibility of having any world that is named Kerbin be the homeworld, as opposed to depending on the homeworld actually
having a Kerbin template.

This feature makes it possible that the IC plugin dynamically assigns the name Kerbin to whichever world is defined as the homeworld.
In the InterstellarConsortium node of your star config you can include a home parameter set to the name of the body that serves as
the homeworld around the star. If your star has no homeworld, don't include the parameter. If you open the file
GameData/InterstellarConsortium/InterstellarConsortium.cfg you will find a value home, you can change this to point at
the star you want to start at. You can override the default home planet using the homePlanet option as well.

What happens when you set those values is, that the IC plugin first searches every body called Kerbin or Sun and assigns them a
randomly generated name. Then it assigns the name Sun to the selected home star and the name Kerbin to the associated home planet.
The positioning system now shifts all positions by the position of the selected home star, so that the home star is at 0, 0, 0, i.e.
the center of the galaxy. All other calculations now use the shifted positions, which means all other stars orbit the selected home star
now. The bodies will keep their original names for the user, since their displayName isn't changed, only the internal name changes.

However, the dynamic names impose one problem: Every mod that references a body by it's internal name will break as soon as the names of
that body change. Take for example an EVE cloud configuration that targets Kerbin. As soon as you change your home world to, let's say,
Gael from GPP that Kerbin configuration would suddenly target Gael because internally, it would be named Kerbin. The same applies for
lots of other things, mainly mods like Scatterer etc., but also features like Kopernicus referenceBody tracking (which used the internal
name). When you switch the homeworld all moons that orbit it would move.

The solution to that is simpler than it sounds, a system / standard we called UBI - Unique Body Identifier. It is basically an overlay
over the naming that is imposed by KSP without it's restrictions. As you might know, in KSP the central body has to be named Sun and
the home body has to be named Kerbin to prevent KSP from failing horribly. That also implies that we have to change those names
dynamically to allow for homeworld switching. UBI doesn't have those limitations. In fact, one body can even implement multiple UBIs
and therefor be targeted through multiple names.

A UBI is composed by a system / author name and a body name. You can set the main UBI of a body through the identifier value in the
Body node, like this:

Body
{
    name = Kerbin
    identifier = Squad/Kerbin
}

All UBIs have to follow that format, to a) make their structure more clean and b) make it almost impossible to confuse them with the
internal name. All values that accepted body names in Kopernicus were changed to support UBI, with a fallback to the internal name.
This means, that if a body should orbit around a body with the UBI Squad/Sun, their referenceBody would be Squad/Sun not Sun

A body can implement multiple UBIs through the implements value in the Body node. You can have multiple implements values. This
is especially useful for dynamically assigning "roles" to one body or another. For example, let's take OPM. If it was compatible
with IC, there could be a configuration option to decide, whether it should add itself to the stock system, or whether it should
spawn around another star in the IC galaxy. The idea is, that the OPM bodies could be configured to orbit around a OPM/Sun body,
and that depending on the settings, this UBI would be either assigned to the stock sun (additionally to Squad/Sun) or to a
different star that is spawned for that purpose. That way, the amount of ModuleManager magic that is required is minimal.

At the point of writing, Kopernicus already fully supports UBI. It includes a small helper class that can be copied by other mods to
implement UBI support themselves. If time and motivation allows it we will probably patch some of the more common mods ourselves as
some kind of reference implementation. Configs for those mods could then switch to the UBI syntax as well and full support IC, while
having the same fallback to the internal name that Kopernicus has.

Making a planet pack compatible
The general idea of making a planet pack compatible with IC is porting it to the UBI syntax and adding the InterstellarConsortium
config to your star. If your planet pack doesn't include a star, you have to decide whether it should stay in the stock system,
move around it's own star, or have that part of it be configurable (more about that later). You can use the perviously mentioned
tricks with UBI to limit the amount of ModuleManager magic you have to use.

If you edit planets it becomes a bit more tricky, but not much. Basically what you have to do is copy the planet if you have IC
installed, and still edit it if it isn't. But instead of changing it's properties, the only thing you do is assing an identifier to
it. That means, if you have IC installed the copied body gets the identifier, if you haven't, it gets added to the stock body.
What you can do now is change your main editing config to not target the body using it's name, but using the identifier value.

@Body[Sun]:NEEDS[!InterstellarConsortium]
{
    @identifier = GPP/Sun
}
+Body[Sun]:NEEDS[InterstellarConsortium]
{
    @identifier = GPP/Sun
}
@Body:HAS[#identifier[GPP/Sun]]
{
    // Your edits here
}

In that example, all the GPP planets would use GPP/Sun as their referenceBody, so that they automatically reparent themselves
when IC is installed and the edited body changes into a copied one.
Overall the system, while being rather simple, turned out to be quite powerful and pretty useful for IC as whole.

Configuring planet packs
Previously I mentioned that a user could choose between multiple modes for their planet packs (whether OPM spawns around the stock
sun or a custom one in my example). This is possible because of another feature we have added. In the InterstellarConsortium.cfg
you can add those options into a node called Settings. The IC plugin will take those values, and convert them into :FOR nodes.
This means you can target them using :NEEDS in your configs. For example:

InterstellarConsortium
{
    Settings
    {
        Test = False
        OPM
        {
            SpawnAroundStock = True
        }
    }
}

would produce the following :FOR tags:

•  IC-Test
•  IC-Test-False
•  IC-OPM-SpawnAroundStock
•  IC-OPM-SpawnAroundStock-True

Although it is not a technical requirement, it is recommended to only use Boolean values, since thats how you will use them anyways.

If you have any questions about integrating IC compatiblity into your mod, feel free to ask them here or post them in the
#interstellar-consortium channel on the Kopernicus Discord server.

The download link for the plugin: https://github.com/Kopernicus/interstellar-consortium/releases
Simply extract it into GameData and you should be ready to start using it.

P.S: Please note that IC at the moment is not compatible with ScienceDefs since those don't support UBI. We are working on a solution
for that, but it needs some testing and explaining it here would probably cause total brain input overflow.

Edited January 12, 2019 by Thomas P.

[Athur Dent]

A small question out of technical curiosity:

 

As KSPs main star has an hard-coded, infinite SOI, how are you implementing your SOI-value for the center star? Is it ignored for the central star, or did you find a way to "hack" KSP?

[Whirligig Girl]

1 hour ago, Athur Dent said:

A small question out of technical curiosity:

 

As KSPs main star has an hard-coded, infinite SOI, how are you implementing your SOI-value for the center star? Is it ignored for the central star, or did you find a way to "hack" KSP?

the central star, whatever it may be, will have an infinite SOI. the Stock Sun's soi will only be set to 0.8 if it is no longer the homeworld star.

That's my understanding, but not being a dev I could be wrong

(great username btw)