You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The way the Kopernicus starlight system works means that changing homeworlds will mean stars get unexpected and incorrect luminosity.
We can only define the solar flux at a reference distance in watts/m^2 (called luminosity in the configs, but this is a misnomer) per star. Every star has to use the same value for that reference distance, which is equal to the semiMajorAxis of the homeworld (or the parent body of the homeworld if the homeworld is a moon).
Consider the problem faced by SLIPPIST-1, which is a red dwarf. It is designed to be played standalone, so its luminosity is tuned to the homeworld of that system, Echo/SLIPPIST-1e. Echo's semimajoraxis is 3% that of Kerbin's. This means that when you use Interstellar Consortium in the Kerbol system, SLIPPIST-1's luminosity will be calculated such that you get 894 W/m^2 at the equivalent distance of Kerbin. This effectively makes SLIPPIST-1 a thousand times more luminous than it should be, burning any spacecrafts that dare enter the part of the system that has any planets.
Now it is possible for star system mods to solve this problem with a patch that modifies the "luminosity" value of the star when Interstellar Consortium is installed. But this is not generalized, since it would at best only work for the mod's homeworld and for the stock homeworld. We need a solution that would work in general, for any combination of homeworld and other mods.
There's a couple possible solutions:
1) Fix this problem with changes to Kopernicus.
I can not say for sure if this fix would actually work, but here's what I propose. Introduce a new value, let's call it "LuminosityAU." If this value is not defined in a config, the default behavior is used for that star. If it is defined, then it will be the value used to calculate the true luminosity of the star. So we could simply define a "luminosity" value of 1360 W/m^2, and a distance value of SQRT[Luminosity of star in watts / Luminosity of Sun in watts] * 1 au, to get the true luminosity.
Or we can set the LuminosityAU value to equal the SMA of the homeworld and keep defining "luminosity" as solar flux at the homeworld. But importantly, the "homeworld" will always be the default homeworld, not whatever homeworld is used.
Now the trouble is I don't know if Kopernicus/KSP can support using different "au" values for different stars. It may be that you need to calculate every star with the same distance. In that case a Kopernicus-based approach may be impossible.
2) Fix the problem with Math and ModuleManager
This can either be done with ModuleManager or in the Interstellar Consortium plugin, I imagine.
We can read the semimajoraxis of the homeworld for each star system (either with a manually input value in the IC node, or by looking at the configs themselves). Then using some mathematics (the specifics will depend upon the implementation) we calculate what the luminosity of every star is, and we overwrite the luminosity value with one that corresponds to the new homeworld SMA.
Either way, this is a problem that really needs to be solved, or IC will never work properly
This along with not having a sun patch is the two biggest problems IC has right now.
The text was updated successfully, but these errors were encountered:
The way the Kopernicus starlight system works means that changing homeworlds will mean stars get unexpected and incorrect luminosity.
We can only define the solar flux at a reference distance in watts/m^2 (called luminosity in the configs, but this is a misnomer) per star. Every star has to use the same value for that reference distance, which is equal to the semiMajorAxis of the homeworld (or the parent body of the homeworld if the homeworld is a moon).
Consider the problem faced by SLIPPIST-1, which is a red dwarf. It is designed to be played standalone, so its luminosity is tuned to the homeworld of that system, Echo/SLIPPIST-1e. Echo's semimajoraxis is 3% that of Kerbin's. This means that when you use Interstellar Consortium in the Kerbol system, SLIPPIST-1's luminosity will be calculated such that you get 894 W/m^2 at the equivalent distance of Kerbin. This effectively makes SLIPPIST-1 a thousand times more luminous than it should be, burning any spacecrafts that dare enter the part of the system that has any planets.
Now it is possible for star system mods to solve this problem with a patch that modifies the "luminosity" value of the star when Interstellar Consortium is installed. But this is not generalized, since it would at best only work for the mod's homeworld and for the stock homeworld. We need a solution that would work in general, for any combination of homeworld and other mods.
There's a couple possible solutions:
1) Fix this problem with changes to Kopernicus.
I can not say for sure if this fix would actually work, but here's what I propose. Introduce a new value, let's call it "LuminosityAU." If this value is not defined in a config, the default behavior is used for that star. If it is defined, then it will be the value used to calculate the true luminosity of the star. So we could simply define a "luminosity" value of 1360 W/m^2, and a distance value of SQRT[Luminosity of star in watts / Luminosity of Sun in watts] * 1 au, to get the true luminosity.
Or we can set the LuminosityAU value to equal the SMA of the homeworld and keep defining "luminosity" as solar flux at the homeworld. But importantly, the "homeworld" will always be the default homeworld, not whatever homeworld is used.
Now the trouble is I don't know if Kopernicus/KSP can support using different "au" values for different stars. It may be that you need to calculate every star with the same distance. In that case a Kopernicus-based approach may be impossible.
2) Fix the problem with Math and ModuleManager
This can either be done with ModuleManager or in the Interstellar Consortium plugin, I imagine.
We can read the semimajoraxis of the homeworld for each star system (either with a manually input value in the IC node, or by looking at the configs themselves). Then using some mathematics (the specifics will depend upon the implementation) we calculate what the luminosity of every star is, and we overwrite the luminosity value with one that corresponds to the new homeworld SMA.
Either way, this is a problem that really needs to be solved, or IC will never work properly
This along with not having a sun patch is the two biggest problems IC has right now.
The text was updated successfully, but these errors were encountered: