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

[TruthfulGnome]

32 minutes ago, OhioBob said:

It's likely nothing more will be done on JNSQ, at least not as far as the artwork goes.  @Galileo, who developed all the planets, seems to have lost interest and has moved on to other things.  I can maintain stuff like if a config needs updating, but beyond that I don't want to mess with it.  I want to leave things as is just in case Galileo gets motivated and returns to pick up where he left off.

Fair enough

[GJdude]

I'm unsure if this is a Kopernicus issue or not since I've tried the recent update and it didn't appear to fix anything (as this bug has been present for a few versions now), but lindor has some... Awfully pink rings going on. I'm aware an issue like this can happen on mac versions of the game, but I'm on windows.

Installed via CKAN on 1.9.1, but I've taken a look around the files and they all seem to be in the right place. Any idea what might be causing this?

I'd post my log, but I want to try messing with a few things to pin down some of these issues first.

Edit: turns out I'm getting more visual jank than just this. Kerbin's cloud shadows seem stronger than normal and the horizon and colour looks very off. The horizon bug is present in other visual packs too, so it might not be a JNSQ thing, but it does clearly affect JNSQ. Perhaps Scatterer or Kopernicus are to blame for this particular one? I might bring it up over on that side of things if I determine it to be from a recent update.

Edited January 22, 2021 by GJdude

[Kwebib]

On 1/20/2021 at 7:59 PM, OhioBob said:

Sigma88 is looking into the issue, but in the meantime the following patch appears to fix the problem in JNSQ:

@Kopernicus:AFTER[JNSQ]
{
	@Body[Kerbin]
	{
		@Orbit
		{
			@semiMajorAxis += 0.0001
		}
	}
}

 

Maybe a dumb question, but is this savegame safe?

[OhioBob]

57 minutes ago, Kwebib said:

Maybe a dumb question, but is this savegame safe?

The change is so miniscule that it shouldn't cause any problems.  The patch changes Kerbin's orbital period from 364.999999999999 days to 365.000000000001 days.  That's a difference of 1 second over 11 million years.  However, it's not the size of the change that matters to Kronometer, it's that we went from <365 to >365.  I don't pretend to understand how Kronometer works, but apparently that slight change alters how Kronometer executes its logic/computations.  In one case we get Year 2 starting on Day 0, and in the other we get Year 2 starting on Day 1.

And, as I understand it,  the fact that the day has changed really shouldn't affect anything.  Internally everything should work off a counter that measures elapsed time in seconds from the start of the game.  That counter doesn't change.  All that changes is how Kronometer displays the elapsed time as a date.  The displayed date can be in any format, it really doesn't matter to anything outside of what you see on your monitor.

[Kwebib]

That makes sense. Thank you for the explanation.

[GJdude]

After some more experimentation I narrowed the atmosphere issues down to Scatterer, so don't worry about that one. As for lindor, the rings are still pink.

Here's my log.

Edit: Turns out this occurs when forcing OpenGL. Still don't know what else is behind it, though.

Edited January 23, 2021 by GJdude

[leopardenthusiast]

Pink rings are a known issue with Kopernicus if your game is using OpenGL, which Mac and Linux versions of the game have to.  Why are you forcing OpenGL on Windows, though?  Why not just use DX11?

[Sigma88]

@linuxgurugamer @OhioBob @Kwebib

I think the issue about getting weird results from the calendar has been fixed now.

It was a combination of a Kronometer issue (fixed in the latest release v1.11.0-1) and Kopernicus (already fixed in the dev version, not sure when @R-T-B plans to release it)

[OhioBob]

Kronometer Update

Adding to what @Sigma88 just said, you should update Kronometer in your JNSQ installation.  Kronometer is packaged with JNSQ, so you'll need to replace the Kronometer found in the following folder,

[KSP]/GameData/JNSQ/JNSQ_Plugins/Kronometer

with Kronometer v1.11.0-1 downloaded from GitHub.

The patch I suggested earlier is not needed if you update Kronometer.

 

Edited January 24, 2021 by OhioBob

[R-T-B]

8 hours ago, Sigma88 said:

@linuxgurugamer @OhioBob @Kwebib

I think the issue about getting weird results from the calendar has been fixed now.

It was a combination of a Kronometer issue (fixed in the latest release v1.11.0-1) and Kopernicus (already fixed in the dev version, not sure when @R-T-B plans to release it)

It's released in bleeding edge.  It will be pushed to stable soon, within next day probably.

Edited January 24, 2021 by R-T-B

[GJdude]

On 1/24/2021 at 7:08 AM, leopardenthusiast said:

Pink rings are a known issue with Kopernicus if your game is using OpenGL, which Mac and Linux versions of the game have to.  Why are you forcing OpenGL on Windows, though?  Why not just use DX11?

Forcing glcore saves a stunning amount of ram use, even if it costs a little fps. My install goes down from hogging about 14+ gigs of ram down to about 8 or 9. I have 16 gigs of ram, which should be enough for JNSQ, and I've tried cutting down my modlist several times, and yet KSP still demands on throwing itself right to the limit and forcing all manner of occasional page file slowdown unless I use glcore. I've always wondered, what does glcore do to save ram that DX11 can't do?

[AmateurAstronaut1969]

Because this Mod acts as a sort of a visual mod, do we remove all other visual mods eg: EVE, Spectra, ect... 

[Kwebib]

@Ollz Yes, but you still want EVE and Scatterer plugins. No EVE configs, though, JNSQ has its own.

[AmateurAstronaut1969]

Ok Cheers man

[Dafni]

59 minutes ago, Ollz said:

Because this Mod acts as a sort of a visual mod, do we remove all other visual mods eg: EVE, Spectra, ect... 

Yes and no. You still need EVE, as this is the framework that clouds are build on. And Scatterer needs to stay too, if you want to use it.

But Spectra and similar mods need to go, they might cause conflicts somewhere (in the worst case) or just add unneccesary loading time. These mods are like config collections for EVE and Scatterer etc, and JNSQ comes with its own configs. But the configs wont do anything without the base mods like EVE and Scatterer.

[AmateurAstronaut1969]

Also sorry, by 3GHz Quad Core as A Minimum Processor, does that mean All the Cores have to be 3 (so overall a 12GHz Processor) or all the Cores have to equal 4 ( So in Actuality, Each processor is 0.75GHz)?

 Also is This mod Compatible with KSC Extended?

Edited January 28, 2021 by Ollz

[rettter3]

1 hour ago, Ollz said:

Also sorry, by 3GHz Quad Core as A Minimum Processor, does that mean All the Cores have to be 3 (so overall a 12GHz Processor) or all the Cores have to equal 4 ( So in Actuality, Each processor is 0.75GHz)?

 Also is This mod Compatible with KSC Extended?

The first probably... My old fx 6300 on my old rig already sucked

[AmateurAstronaut1969]

Yeah I checked my Processor and it says like 2.67GHz so I’ll be fine lmao

 

 

(Famous Last Words)

[CDSlice]

7 hours ago, Ollz said:

Also sorry, by 3GHz Quad Core as A Minimum Processor, does that mean All the Cores have to be 3 (so overall a 12GHz Processor) or all the Cores have to equal 4 ( So in Actuality, Each processor is 0.75GHz)?

That's not how processor speed is measured, a 3GHz quad core processor means that each core can run at 3GHz and that you have four such cores. You can't just add up the GHz per core like that, each processor core is independent of the rest so adding them up to say you have a 12GHz processor is wrong because no single core can run at 12GHz.

[AmateurAstronaut1969]

Ok thanks - I’m not a Computer person Lmao

[sturmhauke]

If you have 4 cars driving at 90 kph, is the total speed 360 kph? No. This is the same thing.

[AccidentalDisassembly]

Just out of curiosity - I started playing around with JNSQ planets' radii to see what would happen. To make Kerbin slightly easier to ascend from (for instance), is it as simple as changing the "radius = X" value in Kerbin's .cfg file (in JNSQ_Bodies) to a slightly smaller number (maybe 1,500,000m instead of 1,600,000m, or whatever)? This seems to work in testing, but I have no idea how these numbers might be used by other mods or other parts of JNSQ. Would changing that radius value potentially break other things in unpredictable or unforeseeable ways (for someone with my lack of knowledge)? Kerbal Konstructs facilities, for instance? Or will most other things adapt automatically to whatever radius I set in JNSQ_Bodies/Kerbin.cfg?

EDIT: If I were to modify the radius value via a patch (if this can be done), would I need to modify it at a particular stage of loading, or would :FINAL work, or something like that?

Edited January 30, 2021 by AccidentalDisassembly

[Gordon Fecyk]

Finally made it to Huygen after recent Kopernicus Bleeding Edge update

So a while back I gave up on my original JNSQ Exploration series and tried starting a new save, only to find Kopernicus for KSP 1.9.1 had a similar problem with distant celestial bodies. But after doing the do-over mission, I read about recent changes to Kopernicus Bleeding Edge and found this:

Quote

1.) An attempted bugfix for the bug in which distant bodies would have landing gear and legs sink (as well as poof your kerbals) has been deployed. It seems to work well, but testing is required. Note that teleporting can still trigger the bug, but teleporting has always been glitchy so we don't really plan on fixing that.

While Bon Voyage counts as teleporting for the purpose of this patch, it still seems a lot more stable on Aden and on Huygen. I've still encountered this, but if the game is having this particular fit I found quick-saving, quitting for a while, and coming back seems to work around the problem. I can then drive around for a few more hours and use Bon Voyage without encountering this problem.

I also removed World Stabilizer and this corrected a lot of crumpled rover issues. If I need to, I can pause the game on scene load, and cheat the rover above ground using the stock Set Position tool, to manually stabilize my rovers. I'll do this off-camera in subsequent episodes.

But a combination of these workarounds is allowing me to continue the original series, and I just finished filming at Huygen. No MoHole or MoPole there, but that's OK after the craziness of the do-over series. New episode finally coming this week.

Spoiler

 

[AmateurAstronaut1969]

Is there any configs to Add Rings to Jool, Lindor or both, because you have to admit that planetary Rings have been popular since around 4.5 Million Years ago ( Bit of a Saturn Joke there  ) 

In all Seriousness, I would love a Config for rings if there isn’t one already 

[JadeOfMaar]

49 minutes ago, Ollz said:

Lindor

You've never seen JNSQ's loading screens, huh...

50 minutes ago, Ollz said:

Jool

The desire for rings for Jool is well known and is decidedly overplayed, so JNSQ won't have such configs, otherwise, Lindor would lose its appeal in that department.