Jump to content

[1.2.1] Outer Planets Mod (2.1) - Active development has moved, see first post for new thread


CaptRobau

Recommended Posts

Just noticed that OPM has just past a combined 70,000 downloads on KerbalStuff and Curseforge! I never noticed it passing 60K and 50K was only about a month ago, so that's pretty amazing. I'm glad so many people are enjoying our mod. Everytime someone posts some shot of Sarnus or Tekto on Reddit it always fills my heart with glee.

I'm currently quite busy IRL, so no ETA on Neidon's moons yet. Once RL pressures subside I'll get back to those ASAP.

Link to comment
Share on other sites

Just noticed that OPM has just past a combined 70,000 downloads on KerbalStuff and Curseforge! I never noticed it passing 60K and 50K was only about a month ago, so that's pretty amazing. I'm glad so many people are enjoying our mod. Everytime someone posts some shot of Sarnus or Tekto on Reddit it always fills my heart with glee.

I'm currently quite busy IRL, so no ETA on Neidon's moons yet. Once RL pressures subside I'll get back to those ASAP.

Well, (I think) you already know that I am working on a video of the Outer Planets Mod. It'll still take a while to complete it, I'm afraid. :(

However, when it's finished, y'all will be the first to know! :D

Link to comment
Share on other sites

I've made all naked eyes bodies discovered, just like we already knew all the planets up to Saturn for millennia (since you could see them with the naked eye). Minmus would also have been spotted since ancient times, since it's close enough to be noticeable even to cave Kerbals. I think it's a nice mix between having lots of unexplored stuff, but also already giving players an inkling of what's out there.

Link to comment
Share on other sites

I've made all naked eyes bodies discovered, just like we already knew all the planets up to Saturn for millennia (since you could see them with the naked eye). Minmus would also have been spotted since ancient times, since it's close enough to be noticeable even to cave Kerbals. I think it's a nice mix between having lots of unexplored stuff, but also already giving players an inkling of what's out there.

[one day on the surface of the Mun]

Neil Kerman: "one small step for a kerbal, a giant leap for......"

Kouston: " WAIT!!! what's that green thing orbiting kerbin??? since when there are TWO moons??? come back Neil, you've got to go and land there too"

[some time later on the surface of Minmus]

Neil Kerman: "let's try again, One small step for......"

Kouston: "OMG there's a giant ball of fire in the sky!!!!"

and that's how kerbalkind discovered the Sun :)

Link to comment
Share on other sites

Hello to all,

I have looked through the past pages and searched the post, but i have not found any download to allow this to play nice with SCANSAT.

Have I missed a config file?

Thanks for any info or help.

Cheers.

Didn't realize it needed compatiblity. I do indeed see some planet/moon related stuff in Scansat's configs. I'll see what I can about adding something for that in the next update.

I have played with this ingame and you don't need any config for SCANsat, it uses its own defined colors to add them to custom planets. The only downside is that for some planets you have to zoom very far out in flight view or look via mapview to see any resource overlays.

Tested this both with stock and SCANsat overlays.

Edited by Olympic1
Link to comment
Share on other sites

Didn't realize it needed compatiblity. I do indeed see some planet/moon related stuff in Scansat's configs. I'll see what I can about adding something for that in the next update.

There isn't really anything needed. You could use Module Manager (I think) to add some default terrain color configs for the OPM planets. Add another "Item" like that shown below to the SCANsat_Altimetry node in the SCANcolors.cfg file.


SCANsat_Altimetry
{
Item
{
name = Mun
index = 2
minHeightRange = -500
maxHeightRange = 7000
clampHeight = Null
paletteName = RdGy
paletteSize = 11
paletteReverse = True
paletteDiscrete = False
}
}

The relevant values are the index (the flight globals index), the name, the min and max height range (this sets the upper and lower bounds for the terrain maps, useful for planets with extreme variations in altitude), and maybe some of the palette options, though you would have to be careful about getting the names right if you use anything other than Default.

All of these values can also be set in-game with the SCANsat color management window.

The only downside is that for some planets you have to zoom very far out in flight view or look via mapview to see any resource overlays.

Tested this both with stock and SCANsat overlays.

I'm not sure if Kopernicus has any means for editing this, but there is a value somewhere for setting when the resource overlay textures will become visible. Otherwise there isn't much to do about it.

Link to comment
Share on other sites

The relevant values are the index (the flight globals index), the name, the min and max height range (this sets the upper and lower bounds for the terrain maps, useful for planets with extreme variations in altitude), and maybe some of the palette options, though you would have to be careful about getting the names right if you use anything other than Default.

if the flightGlobalsIndex is required it could be a problem, since Kopernicus re-calculates the flightGlobalsIndex of the custom planets and overwrites the value you set in the cfg. (or at least I think kopernicus is supposed to do that)

So basically if someone has more than one planet pack installed it could potentially mess up everything.

Btw, why would a cfg require both name and flightglobalsindex?

Link to comment
Share on other sites

if the flightGlobalsIndex is required it could be a problem, since Kopernicus re-calculates the flightGlobalsIndex of the custom planets and overwrites the value you set in the cfg. (or at least I think kopernicus is supposed to do that)

The flightGlobalsIndex for the Sun, Kerbin, Mun, and Minmus are hardcoded from 0 - 3. The other stock planets are given a FGI from 4 - 16 (like it is normally).

For custom planets: Kopernicus gets the FGI from its planet configs and gives them a new FGI.

Example:

Planets load in game in following order

- 50

- 173

- 85

- 86

- 213

Kopernicus gives them new FGI's in following order:

- 50 becomes 17

- 85 becomes 18

- 86 becomes 19

- 173 becomes 20

- 213 becomes 21

I don't know what number is assigned to a config without a FGI. I think it is given one in order of appearance.

Edited by Olympic1
Link to comment
Share on other sites

The flightGlobalsIndex for the Sun, Kerbin, Mun, and Minmus are hardcoded from 0 - 3. The other stock planets are given a FGI from 4 - 16 (like it is normally).

For custom planets: Kopernicus gets the FGI from its planet configs and gives them a new FGI.

Example:

Planets load in game in following order

- 50

- 173

- 85

- 86

- 213

Kopernicus gives them new FGI's in following order:

- 50 becomes 17

- 85 becomes 18

- 86 becomes 19

- 173 becomes 20

- 213 becomes 21

I don't know what number is assigned to a config without a FGI. I think it is given one in order of appearance.

so you can't know for sure the FGI of your planets, right?

in order to write this config you need to know it before hand If I am not misunderstanding it


SCANsat_Altimetry
{
Item
{
name = Mun
[COLOR=#ff0000][B] index = 2[/B][/COLOR]
minHeightRange = -500
maxHeightRange = 7000
clampHeight = Null
paletteName = RdGy
paletteSize = 11
paletteReverse = True
paletteDiscrete = False
}
}

Link to comment
Share on other sites

Btw, why would a cfg require both name and flightglobalsindex?

Actually it doesn't, I guess I just put it in there for clarity.

so you can't know for sure the FGI of your planets, right?

in order to write this config you need to know it before hand If I am not misunderstanding it

That does complicate things. So adding OPM (or any other Kopernicus) configs beforehand is probably a bad idea (using MM in general might actually be a bad idea for config files like this, it isn't really designed for it). Luckily, the values can be set in-game pretty easily.

When KSP first loads, SCANsat reads all of the terrain configs from the file at the main menu. It searches for planets that match the index number and assigns each terrain config to its matching planet. If there is no planet with that index number then it will just drop that config (there is a potential bug here that needs to be fixed), if the index matches a different planet than what is intended then you will end up with mismatches.

If there is no config for a planet in your game it won't be a problem. It won't even come up until you've visited that planet at least once. At that point SCANsat will see that there is no terrain config for that planet and it will assign one. After a config is assigned for a planet you can edit and save it to the config file using the color management window.

If the numbers get mixed up at some later date this will cause mismatches, but I hope there is some system in place to avoid this. Planet index values are used all over the place, most notably in contracts when assigning a target planet.

Link to comment
Share on other sites

Actually it doesn't, I guess I just put it in there for clarity.

That does complicate things. So adding OPM (or any other Kopernicus) configs beforehand is probably a bad idea (using MM in general might actually be a bad idea for config files like this, it isn't really designed for it). Luckily, the values can be set in-game pretty easily.

When KSP first loads, SCANsat reads all of the terrain configs from the file at the main menu. It searches for planets that match the index number and assigns each terrain config to its matching planet. If there is no planet with that index number then it will just drop that config (there is a potential bug here that needs to be fixed), if the index matches a different planet than what is intended then you will end up with mismatches.

If there is no config for a planet in your game it won't be a problem. It won't even come up until you've visited that planet at least once. At that point SCANsat will see that there is no terrain config for that planet and it will assign one. After a config is assigned for a planet you can edit and save it to the config file using the color management window.

If the numbers get mixed up at some later date this will cause mismatches, but I hope there is some system in place to avoid this. Planet index values are used all over the place, most notably in contracts when assigning a target planet.

You should probably get in touch with Kopernicus devs then, I honestly would rather kopernicus still generated the FGI, since that allows for a better "TAB" navigation in the tracking station.

For example, OPM FGIs in order are:

Sarnus

Urlum

Neidon

SarnusMoons

UrlumMoons

if you go in the tracking station and press TAB you would see

DUNA

Ike

JOOL

goes through every JoolMoons

then jumps to Eeloo (which is in orbit around sarnus)

then goes back to Sarnus

skips to Urlum

then Neidon

goes back to the Sarnus moons

jumps to the UrlumMoons

and finally goes to Plock

it's a mess :)

edit:

and even if OPM devs were to fix the FGIs in order to make them more "fluid" there's still the problem of using more than one planets pack.

of course if this is the only way it will have to suffice, and a little more coordination will be needed in the choosing of FGIs

Edited by Sigma88
Link to comment
Share on other sites

Same for me, and I'm using planets from K+ to add moons and inner dwarf planets along with Trans-Keptunian. I have changed non of the FGI's and everything still comes up in the logical order: Kerbol, planet, moons, next planet, its moons, etc.

Also, to the devs. We know you're busy with RL and stuff, but any chance of a sneak peak? :P I'm sure I speak for all of us when I say we can't wait to see what the Neidon system will look like!

Link to comment
Share on other sites

In my game if I TAB in the tracking station it goes normally in order of appearance.

So Joolian moons and then sarnus, etc..

yeah, because kopernicus recalculates the FGIs, if you try the older versions of kopernicus where the only way was to set FGIs manually the result was the one I described ;)

Link to comment
Share on other sites

The past few days I was updating the wiki's templates and pages. I fixed some templates that needed fixing for a long time, and I added some more info to the planets and some other pages.

Now I came across Hale and because it's orbiting in the rings of Sarnus, it's a shepherd moon.

Because Hale is also orbiting in a gap (of the ring), I need a fan based name (or by the dev's) for that gap. It would be best if it isn't a real life name of a gap.

Link to comment
Share on other sites

The past few days I was updating the wiki's templates and pages. I fixed some templates that needed fixing for a long time, and I added some more info to the planets and some other pages.

Now I came across Hale and because it's orbiting in the rings of Sarnus, it's a shepherd moon.

Because Hale is also orbiting in a gap (of the ring), I need a fan based name (or by the dev's) for that gap. It would be best if it isn't a real life name of a gap.

Kassini divison?
Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...