[1.3] [Kopernicus] New Horizons v2.0.1 [2JUN17] - It's Back!

[linuxgurugamer]

Just reviewed @GregroxMun's fork, and it has some issues with the MM patches (uses FOR)

[Stone Blue]

5 minutes ago, linuxgurugamer said:

... I don't see any changes to the mod, just supporting files such as the readme, license, etc

Wow.. i see theres lots of branches on Lisias' repo...
What about changes he made specifically for his KSP 1.4.5 release? vOv
https://github.com/net-lisias-kspu/New_Horizons/releases

Edited December 31, 2019 by Stone Blue

[linuxgurugamer]

Just now, Lisias said:

Look again.

https://github.com/net-lisias-kspu/New_Horizons/releases/tag/RELEASE%2F2.0.1.1

Also keep in mind that this is on the KSPU hierarchy - are things I'm doing for me for fixing things by me (since all of them being "Unofficial").

Oh, thanks, I'll look at that.

I am well aware these are for the KSPU stuff, but thanks for the mention.  What I'm looking for are changes which should be incorporated into my branch

 

2 minutes ago, Lisias said:

Look again.

https://github.com/net-lisias-kspu/New_Horizons/releases/tag/RELEASE%2F2.0.1.1

I can't look at source code, I'm using Github's PR mechanism to generate and show me the differences.  You have a lot of branches, but none of them indicates they are the branch for that release, so which branch should I use?

[Whirligig Girl]

1 hour ago, linuxgurugamer said:

Just reviewed @GregroxMun's fork, and it has some issues with the MM patches (uses FOR)

Can you please clarify what the problem is?

[linuxgurugamer]

32 minutes ago, GregroxMun said:

Can you please clarify what the problem is?

You haveFOR[NewHorizons]", which is unnecessary.  What you should have is: ":NEEDS[!GalacticNeighborhood]:AFTER[Kopernicus]"

Also, why did you rename all the planets with NH, was it just to make it easier to remember?

[Whirligig Girl]

10 minutes ago, linuxgurugamer said:

You haveFOR[NewHorizons]", which is unnecessary.  What you should have is: ":NEEDS[!GalacticNeighborhood]:AFTER[Kopernicus]"

Also, why did you rename all the planets with NH, was it just to make it easier to remember?

I supported Interstellar Consortium, which makes all planet packs installed share a universe. Galactic Neighborhood's support of NH just removed the stock bodies from the NH system, but this solution wasn't acceptable for Interstellar Consortium, for which one of the goals is that you could play starting from any planet pack that by default has a homeworld. So I renamed all the planets, both internally with NH_[name] for name and identifier, to preserve compatibility with IC and the stock system, and when IC is installed I also change the name displayed in-game.

I don't provide any compatibility with GalacticNeighborhood in my version. Using :FOR[MyMod] is the standard for patching in planet packs, afaik you shouldn't be doing @Kopernicus:AFTER[Kopernicus].

[OhioBob]

@linuxgurugamer, I've looked over the atmospheres.  If it were my mod, I'd scrap it all and start over.  I just don't see enough there worth salvaging.  But that's just me, I like things realistic.  If you don't care about realism, I could probably just fix the few problems already addressed and leave it at that.  I don't mind redoing things - now it actually a good time for me to work on it.  Just give me the word and I'll get started.  If you don't want a complete overhaul, then let me know and I'll just patch things up a little bit.

[linuxgurugamer]

13 minutes ago, OhioBob said:

@linuxgurugamer, I've looked over the atmospheres.  If it were my mod, I'd scrap it all and start over.  I just don't see enough there worth salvaging.  But that's just me, I like things realistic.  If you don't care about realism, I could probably just fix the few problems already addressed and leave it at that.  I don't mind redoing things - now it actually a good time for me to work on it.  Just give me the word and I'll get started.  If you don't want a complete overhaul, then let me know and I'll just patch things up a little bit.

do you mean scrap all the atmospheres?  If you are willing, then go for it. and Thank You!!!!

[OhioBob]

1 hour ago, linuxgurugamer said:

do you mean scrap all the atmospheres?  If you are willing, then go for it. and Thank You!!!!

Yes, the atmospheres.  Not the whole mod. lol

While I'm working on it, if I see anything else that needs revision I'll let you.

[Whirligig Girl]

@linuxgurugamer @OhioBob instead of working on separate forks, why don't we merge our versions of the project so we don't have two competing versions? My version has working support for Interstellar Consortium as well as a patch that makes the NH sun a unique new star rather than an impossible stock-Sun clone.

Edited December 31, 2019 by GregroxMun

[OhioBob]

@GregroxMun, I didn't know you had a version.  I don't keep tabs on what others are doing.  I just volunteered to help out when I got a ping from LGG, basically I'm a sub-contractor.  If you guys want to team up, that's fine with me.

 

 

[linuxgurugamer]

7 hours ago, GregroxMun said:

I don't provide any compatibility with GalacticNeighborhood in my version. Using :FOR[MyMod] is the standard for patching in planet packs, afaik you shouldn't be doing @Kopernicus:AFTER[Kopernicus].

If you look closely, you would have seen that it was a NOT (!) GalacticNeighborhood.

And the FOR is useless in your case, quoting the MM wiki

Quote

A FOR[Blah] defined would allow NEEDS[Blah]

A FOR would be used to define something other than the mod it's in.  There is no need to define FOR[NewHorizons] since it is in the mod NewHorizons  Slight correction about this.  The mod directory is called New_Horizons, the FOR you have is defining NewHorizons (no underscore).  But as far as I can see, it's not used by anything else.

BTW, the following is the way it is in the original mod:

NEEDS[!GalacticNeighborhood]:AFTER[Kopernicus]

 

And I define the AFTER to make sure that all the standard Kopernicus configs are evaluated, and then the NewHorizons's configs.  This way if NH needs something which is defined in Kopernicus, it will be available.  I suppose that the AFTER could be replaced with a NEEDS, but that's debatable.

4 hours ago, GregroxMun said:

@linuxgurugamer @OhioBob instead of working on separate forks, why don't we merge our versions of the project so we don't have two competing versions? My version has working support for Interstellar Consortium as well as a patch that makes the NH sun a unique new star rather than an impossible stock-Sun clone.

I wouldn't mind at all.  I did a test pull from your fork, and there aren't any conflicts.  But, looking at the diffs, I think that there are some fundamental differences in the approaches.

How would you want to approach this?

I'm involved with another group with KCT, the way it worked, I merged in their changes (for RO), and then pushed my changes to them, recently we merged to make mine the main release of it.

Can you explain why you changed the identifiers for all the bodies to this:  NH/Arin

In fact, looking at all the diffs, it seems that most if not all of them are either the difference in the FOR vs AFTER, and specifically changing/adding these new identifiers to everything.  I did notice the big addition for the Sun for Interstellar Consortium, and the new config for the Interstellar Consortium at the end.

After considering this, I think that both can be used;  Add the FOR after the AFTER[Kopernicus] so the final result would be (using the Eeloo config from the original):

@Kopernicus:NEEDS[!GalacticNeighborhood]:AFTER[Kopernicus]:FOR[NewHorizons]

I'd like to use the new atmospheres that @OhioBob is making for me. 

Edit:  I've looked at JNSQ and GPP re. the AFTER.  I'm a bit surprised, but apparently the AFTER isn't needed.  But we would still need to keep the NEEDS[!GalacticNeighborhood] since that's in the original.

Let me know how you would like to proceed

[Snark]

23 hours ago, linuxgurugamer said:

A FOR would be used to define something other than the mod it's in.  There is no need to define FOR[NewHorizons] since it is in the mod NewHorizons  Slight correction about this.  The mod directory is called New_Horizons, the FOR you have is defining NewHorizons (no underscore).  But as far as I can see, it's not used by anything else.

My understanding is that actually, FOR is more important than you think.  I believe the best practice is that you should alwaysinclude :FOR[MyMod] for all the config files for MyMod

The reason's a bit subtle.  It's not the end of the world if you don't follow it... however, apparently ModuleManager's handling of :BEFORE and :AFTER depend on your using :FOR appropriately.  If you omit it, then I think (IIRC) BEFORE won't work-- if someone else makes a mod and then tries to do :BEFORE your mod... it actually will ignore that and end up getting applied after your mod anyway.  So for maximum friendliness and compatibility with other mods that may want to set their order relative to yours, always include this.

[linuxgurugamer]

37 minutes ago, Snark said:

My understanding is that actually, FOR is more important than you think.  I believe the best practice is that you should alwaysinclude :FOR[MyMod] for all the config files for MyMod

The reason's a bit subtle.  It's not the end of the world if you don't follow it... however, apparently ModuleManager's handling of :BEFORE and :AFTER depend on your using :FOR appropriately.  If you omit it, then I think (IIRC) BEFORE won't work-- if someone else makes a mod and then tries to do :BEFORE your mod... it actually will ignore that and end up getting applied after your mod anyway.  So for maximum friendliness and compatibility with other mods that may want to set their order relative to yours, always include this.

So the FOR should be the name of the mod, as in, the mod directory, in this case.  

Which leads to the issue that @GregroxMun's version has "FOR[NewHorizons]"  when the directory name is "New_Horizons", so which is correct?

[zer0Kerbal]

1 hour ago, linuxgurugamer said:

So the FOR should be the name of the mod, as in, the mod directory, in this case.  

Which leads to the issue that @GregroxMun's version has "FOR[NewHorizons]"  when the directory name is "New_Horizons", so which is correct?

IIRC MM ignores the space or the _ character so "NewHorizons" should correct.

and what @Snark says about :FOR seems correct from what I remember, and my own personal experience.

[OhioBob]

As I understand it, this is the order of execution:

:FIRST

:LEGACY (or any patch without a tag)

:BEFORE[A]
:FOR[A]
:AFTER[A]

:BEFORE[Z]
:FOR[Z]
:AFTER[Z]

:LAST[A]
:LAST[Z]

:FINAL

I'm not sure how important FOR is, though I typically use FOR[MyMod].  I do know that FOR is one of the things Kopernicus uses to identify something as a mod so that other mods can reference it using BEFORE and AFTER.  But it's not the only way.  I believe that any folder in GameData is tagged as a mod and can be referenced using BEFORE/AFTER.  So I don't think FOR is strictly necessary.  But using FOR[MyMod] definitely tags "MyMod" as a mod that can be referenced, and that's regardless of whether there is a "MyMod" folder in GameData or not.

[Stone Blue]

Definately dont quote me on this, but IIRC, using :FOR[mod], basically creates some kind of instance for that mod, if that mod does not already exist. Hence, I believe I have heard it should be reserved for a specific mod's official dev, and its not the best idea for modders/patchers to use, *unless* they *are* the said mod's owner/developer. I assume the reasoning is, if a :FOR[ ] is used by not-the-mod-owner, it can potentially cause issues if someone then installs that actual official mod, possibly causing conflicts with what is in the official mod, and possibly create support issues for the real mod's dev... vOv

Again, dont quote me, but something possibly for people to check out/think about before extensively using it.

[linuxgurugamer]

1 hour ago, OhioBob said:

As I understand it, this is the order of execution:

:FIRST

:LEGACY (or any patch without a tag)

:BEFORE[A]
:FOR[A]
:AFTER[A]

:BEFORE[Z]
:FOR[Z]
:AFTER[Z]

:LAST[A]
:LAST[Z]

:FINAL

I'm not sure how important FOR is, though I typically use FOR[MyMod].  I do know that FOR is one of the things Kopernicus uses to identify something as a mod so that other mods can reference it using BEFORE and AFTER.  But it's not the only way.  I believe that any folder in GameData is tagged as a mod and can be referenced using BEFORE/AFTER.  So I don't think FOR is strictly necessary.  But using FOR[MyMod] definitely tags "MyMod" as a mod that can be referenced, and that's regardless of whether there is a "MyMod" folder in GameData or not.

 

15 minutes ago, Stone Blue said:

Definately dont quote me on this, but IIRC, using :FOR[mod], basically creates some kind of instance for that mod, if that mod does not already exist. Hence, I believe I have heard it should be reserved for a specific mod's official dev, and its not the best idea for modders/patchers to use, *unless* they *are* the said mod's owner/developer. I assume the reasoning is, if a :FOR[ ] is used by not-the-mod-owner, it can potentially cause issues if someone then installs that actual official mod, possibly causing conflicts with what is in the official mod, and possibly create support issues for the real mod's dev... vOv

Again, dont quote me, but something possibly for people to check out/think about before extensively using it.

FOR says that the modname is available, as if the mod was actually there.  Doing a FOR in the same mod is pretty much useless, AFAIK, other than to make it obvious what the file is for.  Doesn't hurt to do that, but doesn't really do anything.  As soon as the file is read, the mod is known to MM and other MM scripts

 

[Ronsero]

Still I am wondering why I have a different ambient temperature when I point my ship in a certain direction (or just move the camera)

[OhioBob]

1 hour ago, Ronsero said:

Still I am wondering why I have a different ambient temperature when I point my ship in a certain direction (or just move the camera)

Are you using a thermometer?  The thermometer doesn't read the ambient temperature, it reads the temperature of the thermometer.  So the temperature reading can be affected by the orientation of the vessel.  For instance, greater exposure to the sun will read a higher temperature.  If you want to read the true ambient temperature, I recommend using the Aero GUI from the cheat menu.

[OhioBob]

@linuxgurugamer @GregroxMun,

I'm about halfway finished with the atmospheres, but I'm now running into some issues that I want to get your opinions on.  As I always do, I'm trying to make these atmospheres reasonably realistic.  That's not really a problem for most of the planets, but since the stock planets have been moved from their original positions, this is creating some inconsistencies that cannot be realistically explained.

To assure that Kerbin remains earthlike, I've assumed that the solar flux at Kerbin is the same as it is in stock (1360 W/m²).  From that I've computed the solar flux at other planets (using inverse square law) and computed those planets' effective temperatures.  The effective temperature then becomes the basis for developing a global temperature model.  An atmospheric planet really can't be any cooler than its effective temperature (it is typically hotter due to greenhouse effect).

One of the first planets I worked on was Laythe.  In New Horizons Laythe has been moved from being a moon of Jool to being a planet inside the orbit of Kerbin (the orbit of Sonnah actually since Kerbin is now a moon).  When I compute Laythe's effective temperature I get a value of 328 K, with the temperature at daytime noon above the boiling point of water.  At these temperatures, Laythe could never retain its oceans, they would have evaporated long ago.

So that's my quandary, we have a planet that could never exist in real life in its current state.  So what to do about it?  We could change Laythe to a dry desert world, but I don't think changing the planets in that way is the intent behind New Horizons.  I could change the planet's temperature to something that would be conducive to an ocean world, but that would be unrealistic and inconsistent with the planet's position relative to the sun.  Or we could just marry the realistic atmosphere to the existing planet and not worry about the inconsistency, or try to explain it.

Opinions?

I think my preference is for the last option.  Just compute the atmospheres realistically (which is what I have been doing so far), slap them on the planet, and don't worry about what conflicts may arise.

Edited January 3, 2020 by OhioBob

[linuxgurugamer]

18 minutes ago, OhioBob said:

@linuxgurugamer @GregroxMun,

I'm about halfway finished with the atmospheres, but I'm now running into some issues that I want to get your opinions on.  As I always do, I'm trying to make these atmospheres reasonably realistic.  That's not really a problem for most of the planets, but since the stock planets have been moved from their original positions, this is creating some inconsistencies that cannot be realistically explained.

To assure that Kerbin remains earthlike, I've assumed that the solar flux at Kerbin is the same as it is in stock (1360 W/m²).  From that I've computed the solar flux at other planets (using inverse square law) and computed those planets' effective temperatures.  The effective temperature then becomes the basis for developing a global temperature model.  An atmospheric planet really can't be any cooler than its effective temperature (it is typically hotter due to greenhouse effect).

One of the first planets I worked on was Laythe.  In New Horizons Laythe has been moved from being a moon of Jool to being a planet inside the orbit of Kerbin (the orbit of Sonnah actually since Kerbin is now a moon).  When I compute Laythe's effective temperature I get a value of 328 K, with the temperature at daytime noon above the boiling point of water.  At these temperatures, Laythe could never retain its oceans, they would have evaporated long ago.

So that's my quandary, we have a planet that could never exist in real life in its current state.  So what to do about it?  We could change Laythe to a dry desert world, but I don't think changing the planets in that way is the intent behind New Horizons.  I could change the planet's temperature to something that would be conducive to an ocean world, but that would be unrealistic and inconsistent with the planet's position relative to the sun.  Or we could just marry the realistic atmosphere to the existing planet and not worry about the inconsistency, or try to explain it.

Opinions?

I think my preference is for the last option.  Just compute the atmospheres realistically (which is what I have been doing so far), slap them on the planet, and don't worry about what conflicts may arise.

I like the last, but couldn’t it be explained by having a very strong magnetic field which deflects most of the radiation?

[OhioBob]

40 minutes ago, linuxgurugamer said:

I like the last, but couldn’t it be explained by having a very strong magnetic field which deflects most of the radiation?

A magnetic field would deflect changed particles, but not radiant heat.

Raising Laythe's albedo would bring it's temperature down.  For instance, if Laythe had an albedo of 0.75 (rather than the default 0.3), that would be enough to bring it's temperature down to something earthlike.  But to have an albedo that high would mean Laythe would be completely covered by clouds.  I suppose that's possible, but it's not the way Laythe is depicted in game.

I could change Laythe's albedo and recompute the atmosphere accordingly.  I'm now leaning toward this as our solution.  It would provide a realistic explanation for the lower temperature and the existence of oceans.  The only discrepancy then would be the visual depiction of Laythe with EVE clouds, where the cloud cover is much too sparse.

 

[OhioBob]

The other body for which I might have a similar problem is Eve.  Even in stock KSP Eve is too hot for liquid water, but in New Horizons Eve is even hotter.  Of course the usual explanation for Eve's oceans is that they're not water, but perhaps a hydrocarbon of some type.  In the case of stock Eve the temperature and pressure is just about right for heavy hydrocarbons to exist as liquid on its surface.  I haven't investigated yet how plausible it is with the hotter Eve.  I might have to raise its albedo too to bring the temperature down.  We'll see.

[linuxgurugamer]

I gather that both Galelio’s Planet Pack and JNSQ planet pack have better basic design?