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

[dylsh]

The OP states that Kerbin is switched to a 12hr day. Yet my game is still working off a 6hr day. Any ideas why? Thank you in advance!

[OhioBob]

On 8/23/2021 at 2:59 PM, dylsh said:

The OP states that Kerbin is switched to a 12hr day. Yet my game is still working off a 6hr day. Any ideas why? Thank you in advance!

If you are playing KSP 12.x, then the Kronometer packaged with JNSQ is outdated.  Delete the folder JNSQ/JNSQ_Plugins/Kronometer, then download and install this version of Kronometer:

Release 1.12.0 · linuxgurugamer/Kronometer · GitHub

 

Edited August 25, 2021 by OhioBob

[panarchist]

On 8/22/2021 at 8:34 PM, OhioBob said:

Yes, but just not JNSQ, it can happen for all celestial bodies.  How much the signal passes through a body depends on the game difficulty.  You can change it by adjusting the "Occlusion modifier" slider in the game difficulty settings.  As I understand it, a modifier of 1 means that the body will occlude any signal where the line-of-sight passes below sea level.  Modifiers less than 1 will allow signals to pass through the the outer edges of the body.  While modifiers greater than 1 can occlude signals even if the line-of-sight clears the edge of the body.

 

It's a shame it's not more configurable - IRL planets w/o an atmosphere would have an occlusion modifier of 1, but with an atmosphere, some wavelengths can bend partially around the planet, and might have occlusion modifiers closer to stock. That may be *why* they aren't "1" in stock for all I know.

[OhioBob]

32 minutes ago, panarchist said:

It's a shame it's not more configurable - IRL planets w/o an atmosphere would have an occlusion modifier of 1, but with an atmosphere, some wavelengths can bend partially around the planet, and might have occlusion modifiers closer to stock. That may be *why* they aren't "1" in stock for all I know.

There are separate occlusion modifiers for atmospheric and non-atmospheric bodies, so it's possible to do what you suggest -- set it to 1 for non-atmospheric and, say, something like 0.8-0.9 for atmospheric (I don't know what would be realistic).  Of course even with the modifier set to 1, a signal could still pass through mountains.  It's my understanding that for occlusion the body is considered a sphere with a radius equal the body's specified radius times the occlusion modifier.  So terrain features aren't considered, which is a reasonable simplification.  Of course it gets weird for a small irregularly shaped body, like Gilly or Bop.  An irregular body might be a situation where we'd want to set the modifier >1 (say close to the mean radius), but it's not configurable by body.

[jefferyharrell]

For anybody who's interested, @linuxgurugamer has released a new version of Kronometer that appears to solve the problems people were having with it:

 

[dylsh]

On 8/23/2021 at 3:23 PM, OhioBob said:

If you are playing KSP 12.x, then the Kronometer packaged with JNSQ is outdated.  Delete the folder JNSQ/JNSQ_Plugins/Kronometer, then download and install this version of Kronometer:

Release 1.12.0 · linuxgurugamer/Kronometer · GitHub

 

Thank you so much for your speedy explaination. Fantastic mod! I truly believe this is the scale this game should be played in. It’s actually frustrating because I can’t even play stock anymore. The stock scale feels too aracady. Thanks again for all your hard work!

[mdapol]

Getting this error in my 1.12.1 game:

 

[LOG 19:53:04.415] [Trajectories] v2.4.1 Starting
[ERR 19:53:04.420] Exception loading ScenarioModule Trajectories: System.TypeInitializationException: The type initializer for 'Trajectories.Settings' threw an exception. ---> System.Reflection.ReflectionTypeLoadException: Exception of type 'System.Reflection.ReflectionTypeLoadException' was thrown.
  at (wrapper managed-to-native) System.Reflection.Assembly.GetTypes(System.Reflection.Assembly,bool)
  at System.Reflection.Assembly.GetTypes () [0x00000] in <9577ac7a62ef43179789031239ba8798>:0
  at AssemblyLoader+LoadedAssembyList.GetPathByType (System.Type type) [0x00020] in <cd473063d3a2482f8d93d388d0c95035>:0
  at AssemblyLoader.GetPathByType (System.Type type) [0x00000] in <cd473063d3a2482f8d93d388d0c95035>:0
  at KSP.IO.IOUtils.GetFilePathFor (System.Type T, System.String file, Vessel flight) [0x00005] in <cd473063d3a2482f8d93d388d0c95035>:0
  at KSP.IO.PluginConfiguration.CreateForType[T] (Vessel flight) [0x00000] in <cd473063d3a2482f8d93d388d0c95035>:0
  at Trajectories.Settings..cctor () [0x00007] in <54b43012425c4547b2c53f8eb9f179ca>:0
   --- End of inner exception stack trace ---
  at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_generic_class_init(intptr)
  at Trajectories.Trajectories.OnLoad (ConfigNode node) [0x0000b] in <54b43012425c4547b2c53f8eb9f179ca>:0
  at ScenarioModule.Load (ConfigNode node) [0x0000e] in <cd473063d3a2482f8d93d388d0c95035>:0
  at ScenarioRunner.AddModule (ConfigNode node) [0x0005e] in <cd473063d3a2482f8d93d388d0c95035>:0

 

[danfarnsy]

10 hours ago, OhioBob said:

-- set it to 1 for non-atmospheric and, say, something like 0.8-0.9 for atmospheric (I don't know what would be realistic).

If it could be determined from the atmosphere on a per frequency and angle basis, with some internal reflection due to ionospheres,  you'd probably get a wide range of values. You'd also have dead spots from signal being refracted or reflected away at certain incident angles.

Lacking that, picking 0.9 sounds good to me!

[OhioBob]

11 hours ago, danfarnsy said:

If it could be determined from the atmosphere on a per frequency and angle basis, with some internal reflection due to ionospheres,  you'd probably get a wide range of values. You'd also have dead spots from signal being refracted or reflected away at certain incident angles.

Lacking that, picking 0.9 sounds good to me!

I calculate that for a modifier of 0.9, a radio signal can be received at a station up to about 30-35 degrees beyond the visible horizon.  The angle varies depending on the spacecraft altitude and the size of the celestial body, but 30-35° is about right for most low orbits extending from the top of the atmosphere to several hundred kilometers in height.  Does that sound reasonable?  For a modifier of 0.8 the angle increases to about 45-55° beyond the horizon.

12 hours ago, mdapol said:

Getting this error in my 1.12.1 game:

<snip>

That looks like a Trajectories error.  Not sure why you're posting it in JNSQ.

[danfarnsy]

7 minutes ago, OhioBob said:

The angle varies depending on the spacecraft altitude and the size of the celestial body, but 30-35° is about right for most low orbits extending from the top of the atmosphere to several hundred kilometers in height.  Does that sound reasonable?  For a modifier of 0.8 the angle increases to about 45-55° beyond the horizon.

30° is too much in most cases, but it can happen.

A ground source broadcasting below 30 MHz can have multiple reflections off ground and ionosphere, going around the horizon for thousands of kilometers. For sources outside the atmosphere, at a shallow angle much of the signal will bounce off the ionosphere, for the same reasons things bounce internally, before ever getting a chance to do this. There are exceptions. Above this frequency range, there's little ionospheric interaction, you pretty much need line of sight. Below 1 MHz, you can get a few effects from diffraction around terrain itself, without atmosphere. For just passing through atmosphere, which has an index of refraction slightly different than vacuum, you would expect very slight bending. Planets without significant magnetic fields that can't retain the same kind of ionosphere will also have much less effect.

So, now that I'm chewing on this, picking 0.9 sounds both good and very unrealistic to me.

[panarchist]

On 8/25/2021 at 9:45 AM, OhioBob said:

There are separate occlusion modifiers for atmospheric and non-atmospheric bodies, so it's possible to do what you suggest -- set it to 1 for non-atmospheric and, say, something like 0.8-0.9 for atmospheric (I don't know what would be realistic).  Of course even with the modifier set to 1, a signal could still pass through mountains.  It's my understanding that for occlusion the body is considered a sphere with a radius equal the body's specified radius times the occlusion modifier.  So terrain features aren't considered, which is a reasonable simplification.  Of course it gets weird for a small irregularly shaped body, like Gilly or Bop.  An irregular body might be a situation where we'd want to set the modifier >1 (say close to the mean radius), but it's not configurable by body.

Good to know, thanks. Hard to say what's "realistic" - not all RF frequencies are bent by the ionosphere, and those that are vary by frequency. I'd imagine that anything below 0.9 isn't realistic, because when the ionosphere bends a signal that much, it tends to stay "trapped" in the layer - which is how ham radio signals can communicate with other stations hundreds or thousands of miles away on Earth. Most of the space communication frequencies are high enough that the bending wouldn't be that significant - although GPS sees significant bending, so who knows?

[New Horizons]

Do you experience huge lag when scrolling into Jool or Lindor system? It almost makes no fun to plan gravity assists over there.

[RyanRising]

3 hours ago, New Horizons said:

Do you experience huge lag when scrolling into Jool or Lindor system? It almost makes no fun to plan gravity assists over there.

I do, as well as short freezes when zooming into atmospheric bodies - I believe this is Scatterer loading and unloading the atmospheres of the moons, but I'm not sure.

[Neebel]

On 6/3/2021 at 2:23 AM, Gordon Fecyk said:

The Mun is as challenging to land on as stock Tylo for the unprepared.

A bit late to the party, but according to the JNSQ Delta V map, the Mun requires about 1.600 m/s for descent & ascent. Stock Tylo requires more than 2.200 m/s just for a one-way trip to the surface. Ofc both numbers are to be taken with a grain of salt as it's probably a few 100 m/s more, but the Mun is still a much easier destination in JNSQ then stock's Tylo. Or is that why you put "for the unprepared" in there?

 

Also, one question to everyone, what's a good gravity turn profile to aim for in JNSQ? We started a space-race style JNSQ server but i never played it before. In stock, there's kinda the rule of thumb to aim for a 45° pitch at roughly 10 km, according to my calculations, you should aim for about 12 km in JNSQ because of the larger atmosphere, but is this correct? 

Edited August 30, 2021 by Neebel

[OhioBob]

5 hours ago, Neebel said:

Also, one question to everyone, what's a good gravity turn profile to aim for in JNSQ? We started a space-race style JNSQ server but i never played it before. In stock, there's kinda the rule of thumb to aim for a 45° pitch at roughly 10 km, according to my calculations, you should aim for about 12 km in JNSQ because of the larger atmosphere, but is this correct? 

I don't really pay much attention to pitch vs. altitude.  My rule of thumb is to hold the "time to apoapsis" at about 50 seconds.  If it starts to fall below 50 s, pitch up a little bit, and if it starts to climb above 50 s, pitch down a little.  And if it starts to run away to where I can't control it with pitch alone, throttle back.  Only during the final moments of ascent does the time to apoapsis start to rise well above 50 s.

Edited August 30, 2021 by OhioBob

[Neebel]

20 minutes ago, OhioBob said:

I don't really pay much attention to pitch vs. altitude.  My rule of thumb is to hold the "time to apoapsis" at about 50 seconds.  If it starts to fall below 50 s, pitch up a little bit, and if it starts to climb above 50 s, pitch down a little.  And if it starts to run away to where I can't control it with pitch alone, throttle back.  Only during the final moments of ascent does the time to apoapsis start to rise well above 50 s.

Thanks! Very helpful for new players of JNSQ. 

[Neebel]

On 8/23/2021 at 9:23 PM, OhioBob said:

If you are playing KSP 12.x, then the Kronometer packaged with JNSQ is outdated.  Delete the folder JNSQ/JNSQ_Plugins/Kronometer, then download and install this version of Kronometer:

Release 1.12.0 · linuxgurugamer/Kronometer · GitHub

 

One more question, sorry if I'm annoying, should we put the newly downloaded version of Kronometer in Gamedata or back in JNSQ_Plugins?

[OhioBob]

Just now, Neebel said:

One more question, sorry if I'm annoying, should we put the newly downloaded version of Kronometer in Gamedata or back in JNSQ_Plugins?

It should work in either, but since you're installing it separately, it probably makes more sense just to put it directly in GameData.  We're likely going to delete it from JNSQ in the future, so a separate install is probably going to be the way forward.

[Kerdel]

https://imgur.com/a/gLityoj what does this mean?  i had this before with scatterer and it resets all settings if i press yes

[chris-kerbal]

11 hours ago, Kerdel said:

https://imgur.com/a/gLityoj what does this mean?  i had this before with scatterer and it resets all settings if i press yes

The CKAN description has changed, without a new version of JNSQ. As I remember the install yesterday, Kronometer was made a dependency and is not included in JNSQ anymore. Hence CKAN needs to set that straight, delete the previous JNSQ setup with the included Kronometer and then reinstall JNSQ + the dependency Kronometer as its own package.

It should actually leave your KSP settings.cfg alone and only affect files in the JNSQ folder (or if it happens to other mods the respective folder). You can backup your changed files before doing the reinstall and then copy it back.

[Kerdel]

1 hour ago, chris-kerbal said:

The CKAN description has changed, without a new version of JNSQ. As I remember the install yesterday, Kronometer was made a dependency and is not included in JNSQ anymore. Hence CKAN needs to set that straight, delete the previous JNSQ setup with the included Kronometer and then reinstall JNSQ + the dependency Kronometer as its own package.

It should actually leave your KSP settings.cfg alone and only affect files in the JNSQ folder (or if it happens to other mods the respective folder). You can backup your changed files before doing the reinstall and then copy it back.

Thank you makes sense, I often change files inside mods folders that why i don't like to reinstall mods xD

[Starwaster]

52 minutes ago, Kerdel said:

Thank you makes sense, I often change files inside mods folders that why i don't like to reinstall mods xD

Whenever possible, use ModuleManager patches instead. I too make lots of changes to my game including to the installed mods and those changes are immune to any reinstallation. Those patches lives inside a folder named zzzMyTweaks and it has been with me since at least KSP 0.25 and it's the first thing added to every new KSP install when the game updates.

[flart]

does someone have access to releases on github? There are many PRs and tweaks in the master since 0.9.0, and they could be packaged as 0.9.0.1

[Kerdel]

5 hours ago, Starwaster said:

Whenever possible, use ModuleManager patches instead. I too make lots of changes to my game including to the installed mods and those changes are immune to any reinstallation. Those patches lives inside a folder named zzzMyTweaks and it has been with me since at least KSP 0.25 and it's the first thing added to every new KSP install when the game updates.

i'll take a look into this thanks! i'm just not that known with the commands in cfg's just basic stuff but maybe i can find out myself if i try

[SpaceFace545]

Sooo what is JNSQ_FinalFrontier in the GitHub?