[1.12.1] JNSQ [0.10.0] [23 Sept 2021]

[OhioBob]

2 hours ago, alberro+ said:

Is there any way to make Lindor’s rings more noticeable? At some angles, they can be awfully faint. 

They are suppose to be faint.  Most mod authors give their planets bright Saturn-like rings.  To be different, we wanted to give Lindor faint Uranus-like rings.  I don't know how to brighten them.
 

1 hour ago, EchoLima said:

How difficult is Eve entry intended to be (with FAR)?

I have no experience with FAR, so I haven't the slightest idea.

[Gordon Fecyk]

19 hours ago, EchoLima said:

How difficult is Eve entry intended to be (with FAR)?

Very. The ten metre heat shield was barely enough for me to re-enter at really low Eve orbit. That link takes you to my Part Five  with an Eve lander and the heat shield hit 94% of tolerance.

[FabioofSpace]

Hey, is it possible to play JNSQ on 1.9.1?

[infinite_monkey]

1 minute ago, FabioofSpace said:

Hey, is it possible to play JNSQ on 1.9.1?

Yes, no problem.

[Quoniam Kerman]

On 11/5/2020 at 10:08 PM, OhioBob said:

Not at this time.

To be fair, Parallax even by being eye candy isn't very practical on use. Having ships, kerbals and other objects not really wisually on the ground as they should quite unsettles me. JNSQ textures, although flat are still very beautiful and I think I prefer it that way. 

I am testing Parallax on a stock game for now and I don't really think I'll keep it on the long run to be honest.

[Beetlecat]

2 hours ago, Quoniam Kerman said:

To be fair, Parallax even by being eye candy isn't very practical on use. Having ships, kerbals and other objects not really wisually on the ground as they should quite unsettles me. JNSQ textures, although flat are still very beautiful and I think I prefer it that way. 

I am testing Parallax on a stock game for now and I don't really think I'll keep it on the long run to be honest.

That could be as much the blame of the implementation (configuration) than the idea of it. It looks really great when done well, so maybe the stock configs will get some attention yet. *Then* we can start dreaming about having them for JNSQ bodies

[Akira_R]

So has any one made patches for any contract packs like Anomolay Surveyor or GAP? Technically the contracts all mostly work, but because a number of them reference specific coordinates on stock Kerbin there isn't really anything at a lot of the coordinates they give. A quick search didn't turn up anything, so I was kind of hoping someone had already done the leg work here lol. Does JNSQ even have anomalies around?

[R-T-B]

5 hours ago, Quoniam Kerman said:

To be fair, Parallax even by being eye candy isn't very practical on use. Having ships, kerbals and other objects not really wisually on the ground as they should quite unsettles me. JNSQ textures, although flat are still very beautiful and I think I prefer it that way. 

I am testing Parallax on a stock game for now and I don't really think I'll keep it on the long run to be honest.

I actually made a rough JNSQ pack from the parralax stock textures for Parallax and I agree.  I love parallax but using the stock textures as I did takes something away from JNSQ.  Though flat, the original stock textures are pretty well thought out.  Plus they perform well.

Edited November 15, 2020 by R-T-B

[OhioBob]

9 hours ago, Akira_R said:

JNSQ even have anomalies around?

A few but not many.

[Gordon Fecyk]

I encountered something strange on KSP 1.10.1 and the Kopernicus Bleeding Edge edition. To be fair I'm using a version of Kopernicus that JNSQ does not yet officially support, so I'm not faulting anyone on this. I'd like @R-T-B to look at this at some point, and I'll post an issue at GitHub if needed. But for now, just a background and a question.

I just finished my Krel mission, and I encountered a lot of strange behaviour at the north pole. EVAs would explode on close approach of a Breaking Ground object. Flags would jump to a nearby location when planted, or would just disappear entirely. I've even had my rover lose some pieces depending on the slope of the terrain it sat on. Wheels wouldn't actually touch the ground and thus would have zero traction. However, none of this occurred on prior versions of KSP or Kopernicus. I went back to 1.7.3 and 1.8.1 with their Kopernicus builds and this behaviour didn't occur. I went to 1.9.1 and, while the Breaking Ground objects disappeared, this was better as well.

On a lark I purged the Kopernicus caches and used the current Bleeding Edge Kopernicus, released yesterday. This improved things a lot. EVAs didn't explode when approaching Breaking Ground objects, but it seems the flag would plant right in front of the rover regardless of where the EVA was, and if it was beyond physics range the inputs would lock up. Fortunately I could unlock the inputs using cheats.

So the questions: Is it OK to purge the Kopernicus caches without taking anything away from the JNSQ experience? And should I do this anyway if I change or upgrade Kopernicus versions?

Edited November 17, 2020 by Gordon Fecyk
Further test results

[OhioBob]

@Gordon Fecyk, those are certainly some unusual problems that you describe.  As you said, JNSQ does not yet officially support 1.10.1.  I'm just not yet ready to start debugging problems that may not be directly related to JNSQ, but rather to Kopernicus or some other dependency.

That being said, regarding the cache issue, I don't see why deleting he cache should cause any problems with JNSQ.  Deleting the cache (.bin files) only forces Kopernicus to rebuild them the next time KSP/JNSQ is launched.  You should be able to delete and rebuild them as often as you want; they are just there to save time at startup.

I've never known it to be necessary to delete the cache when upgrading Kopernicus, but it doesn't hurt to do so.  Changes to JNSQ could require new cache files, but we typically update those when a new JNSQ version is released.  Typically anything that changes the size or shape of a celestial body requires updating the cache.
 

Edited November 18, 2020 by OhioBob

[eberkain]

Is there a spreadsheet that contains all the CelestialBodies info?

[KPD87]

21 minutes ago, eberkain said:

Is there a spreadsheet that contains all the CelestialBodies info?

CelestialBodies.pdf is included in the zip-file.

There is also dV-map & antenna ranges too.

Edited November 17, 2020 by KPD87

[eberkain]

3 minutes ago, KPD87 said:

CelestialBodies.pdf is included in the zip-file.

There is also dV-map & antenna ranges too.

Yeah i know, does not answer my question.  I was copying the numbers from the pdf to a spreadsheet, but it is a mess, so i thought one of the devs may already have them in a spreadsheet they may be willing to share. 

[OhioBob]

58 minutes ago, eberkain said:

... so i thought one of the devs may already have them in a spreadsheet they may be willing to share. 

https://www.dropbox.com/s/gcuxvxdnp8yz3cg/JNSQ_PlanetData.zip?dl=0

[JadeOfMaar]

@OhioBob @Gordon Fecyk I've had a B9PS problem on KSP 1.10.1, and I've seen complaints in other mod categories but all unique to this KSP version so (not-very-helpful-comment) I'm confident there are a few glaring base game bugs crawling around right now.

[OhioBob]

1 minute ago, JadeOfMaar said:

I'm confident there are a few glaring base game bugs crawling around right now.

That stinks.  So frustrating when that happens.

[OhioBob]

delete - accidental post.

 

Edited November 18, 2020 by OhioBob

[CDSlice]

7 hours ago, OhioBob said:

That stinks.  So frustrating when that happens.

I will say that I have been running JNSQ in 1.10.1 with bleeding edge Kopernicus and some other mods (Mechjeb, KER, the all of Nertea's mods, SCANsat, and some other mods) and I haven't experienced any bugs or glitches at all so far. 

[Quoniam Kerman]

On 11/17/2020 at 3:41 AM, Gordon Fecyk said:

I encountered something strange on KSP 1.10.1 and the Kopernicus Bleeding Edge edition. To be fair I'm using a version of Kopernicus that JNSQ does not yet officially support, so I'm not faulting anyone on this. I'd like @R-T-B to look at this at some point, and I'll post an issue at GitHub if needed. But for now, just a background and a question.

I just finished my Krel mission, and I encountered a lot of strange behaviour at the north pole. EVAs would explode on close approach of a Breaking Ground object. Flags would jump to a nearby location when planted, or would just disappear entirely. I've even had my rover lose some pieces depending on the slope of the terrain it sat on. Wheels wouldn't actually touch the ground and thus would have zero traction. However, none of this occurred on prior versions of KSP or Kopernicus. I went back to 1.7.3 and 1.8.1 with their Kopernicus builds and this behaviour didn't occur. I went to 1.9.1 and, while the Breaking Ground objects disappeared, this was better as well.

On a lark I purged the Kopernicus caches and used the current Bleeding Edge Kopernicus, released yesterday. This improved things a lot. EVAs didn't explode when approaching Breaking Ground objects, but it seems the flag would plant right in front of the rover regardless of where the EVA was, and if it was beyond physics range the inputs would lock up. Fortunately I could unlock the inputs using cheats.

So the questions: Is it OK to purge the Kopernicus caches without taking anything away from the JNSQ experience? And should I do this anyway if I change or upgrade Kopernicus versions?

The persisting bugs after change of Kop version could as well come from your already cursed missions items on the ground. I sugest you go back to your last save before the landing and retry to see if there is a difference.

[Gordon Fecyk]

5 hours ago, Quoniam Kerman said:

I suggest you go back to your last save before the landing and retry to see if there is a difference.

I did something similar. I went to a prior save as you suggested, but before launching for Lindor as I wanted to check other items I placed at or near north poles. I then cheated my rover / lander to Krel and attempted to reproduce the problems, then attempted this for multiple KSP and Kopernicus versions. This is where I determined that versions prior to 1.10.1 were much better, and even the 1.10.1 kit with Kopernicus BE 46 from 15 NOV behaved better. The flag issues still happened with BE 46 but that was all; I was able to interact with Breaking Ground objects again.

I've yet to test this a lot more thoroughly by cheating craft to other places, but I don't have the time to test as much as I'd like and I still have regular episodes to film. Fortunately, even the 'cursed' save prior to this testing let me plant a flag properly at Krel's equator.

I've seen the lack of traction problem before in a much earlier KSP / Kopernicus version, on a world that used Jool as a template but then added PQS elements to give it a solid surface. The surface was solid enough but it had no friction, kerbals would be stuck lying there, and wheels wouldn't work. This is like some of the behaviours I've seen on Krel here, but a quick save / quick load seemed to work around that.

I'll post the new episode soon, followed by a separate video with all of my tests so far.

[Quoniam Kerman]

Have you enountered this problem on Krel poles?

That could come from a bad template.

[Gordon Fecyk]

5 hours ago, Quoniam Kerman said:

That could come from a bad template.

I'm going to post what I know about JNSQ's templates in a spoiler. If you want to discover this stuff on your own through exploring, please don't proceed further.

Spoiler

The reimagined stock worlds appear to use the original stock worlds as templates, and this seems to let the Breaking Ground objects work along with the original easter eggs and other anomalies. But they've been adjusted somewhat; some anomalies that didn't seem to work on the reimagined worlds were removed. Others were relocated and their surrounding terrain adjusted to accommodate them.

The remaining new worlds all appear to use Moho as a template except for Lindor, and the configurations don't appear to make an effort to remove all of the Moho objects. Thus, it seems Krel has a "mohole" and a random monolith detectable with the RoveMate probe or the ScanSat add-on's parts. I didn't see any Breaking Ground Moho objects on Krel, instead finding Mun Stones that an EVA kerbal could pick up. It was these objects that gave me so much trouble at the north pole. However, using the most recent Kopernicus BE and rebuilding the body caches seems to have corrected that much, leaving the traction problem and the teleporting flags remaining.

Using Moho as a template seemed to work prior to 1.10.1. Aside from finding wild looking objects at the north pole of many worlds, they were mostly harmless unless you ventured through a terrain seam. Maybe R-T-B's Kopernicus BE is having trouble with the actual surfaces of these worlds the further north or south you go, or as others have suggested there might be a problem with Moho's template from the stock game. I'd need to investigate an unmodded game to verify this.

 

[Gordon Fecyk]

Finally made it to Krel!

Spoiler

 

This one hurt. But I'm hoping the rest of Lindor's moons aren't as painful based on my testing.

[OhioBob]

On 11/19/2020 at 9:19 PM, Gordon Fecyk said:

Finally made it to Krel!

This one hurt. But I'm hoping the rest of Lindor's moons aren't as painful based on my testing.

I see in your video that you make some comments about the Mohole at Krel's north pole.  I've done some further investigation into this and I've concluded that it is not because Krel uses a Moho template.  It is the result of a stock bug that was the cause of the Mohole on Moho in the first place.

KSP doesn't like heightmaps that have differences in ground elevation between the north and south poles.  The south pole will appear normal, but if the north pole has a different elevation than the south, KSP will force the north pole to match the elevation of the south by creating either a pit or a spike exactly at the north pole.  Krel just happens to have a pit, but if you visit the north poles of other bodies, you might find a spike.

We typically try to fix this issues by adjusting the heightmaps so there's little or no difference in elevation between the poles, but in some cases, like Krel, it may have gotten overlooked.

I am curious about one thing, however.  Did your scans show the Mohole anomaly at the north pole?  If so, that could still be a problem that we need to look into.  While I believe the physical feature that you found at the pole was the result of a known bug, the identification of it as an anomaly could be a carryover from the template.

(edit)  I just re-watched your video and you clearly say the north pole showed up as an anomaly in your scans.  I need to investigate this further to see if there's a way to eliminate that.

Edited November 21, 2020 by OhioBob