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

[eberkain]

I just want to say, this is such a great looking planet pack.  All the devs that worked on it did a supurb job. 

[Fusion confusion]

GPP + JNSQ = a planet modders worst nightmare

[OrbitalManeuvers]

I was thinking about removing a few palm trees to make room for some KK statics, until I looked into how to do it. Ugh, I'm not quite that motivated, and I don't want to delete them all. Is there any trick to identifying particular instances?

[OhioBob]

10 minutes ago, OrbitalManeuvers said:

I was thinking about removing a few palm trees to make room for some KK statics, until I looked into how to do it. Ugh, I'm not quite that motivated, and I don't want to delete them all. Is there any trick to identifying particular instances?

You can drive out to the palm trees that you want to remove and note the latitude and longitude.  From that you can compute the position vector using the following:

X = COS(latitude) * COS(longitude)
Y = SIN(latitude)
Z = COS(latitude) * SIN(longitude)

You can then find that palm tree in the config as its "repositionRadial" will equal the X, Y, Z values computed above.

(Note that latitude is positive N and negative S, and longitude is positive E and negative W.)

[OrbitalManeuvers]

37 minutes ago, OhioBob said:

COS(longitude)

So using KER I have a degree/min/sec* readout for lat/lon. What's the transformation on that to a COS param? Or is there a better lat/lon display in KSP?

 

edit: * or whatever that's called

Edited December 11, 2020 by OrbitalManeuvers

[OhioBob]

21 hours ago, OrbitalManeuvers said:

So using KER I have a degree/min/sec* readout for lat/lon. What's the transformation on that to a COS param? Or is there a better lat/lon display in KSP?

To enter the coordinates into the formulae I gave you, it is necessary to convert to decimal degrees.  The conversion is,

decimal degrees = degrees + (minutes / 60) + (seconds / 3600)

The answer is positive if north latitude or east longitude, and negative if south latitude or west longitude.

For example, say the coordinates from KER are:

latitude:     0^o 03' 27" N
longitude:     91^o 48' 18" W

We convert to decimal degrees (note that longitude is west, therefore negative):

latitude = 0 + 3/60 + 27/3600 = 0.0575 degrees
longitude = - ( 91 + 48/60 + 18/3600 ) = -91.805 degrees

We now compute the X, Y and Z values:

X = COS(0.0575) * COS(-91.805) = -0.0314979665
Y = SIN(0.0575) = 0.001003564151
Z = COS(0.0575) * SIN(-91.805) = -0.9995033121

Therefore, this object should be the one in Kerbin's config having the following position vector:

repositionRadial = -0.0314979665, 0.001003564151, -0.9995033121

Your computed values and those in the config won't match exactly because you were likely not be at the exact center of the object when you recorded the position, nor are seconds an adequately precise measurement, but the error should be small.  It should be close enough to figure out which object in the config is the one you're trying to locate.

(Note that the coordinates I used in this example are just made up and do not represent any actual object.)

 

Edited December 12, 2020 by OhioBob

[OrbitalManeuvers]

50 minutes ago, OhioBob said:

X = COS(0.0575) * COS(-91.805) = -0.0314979665

Thank you, I really appreciate your help. I don't get the same result for the above equation, so I think I must have some basic misunderstanding. No worries, it's just trees.

 

 

[OhioBob]

13 hours ago, OrbitalManeuvers said:

Thank you, I really appreciate your help. I don't get the same result for the above equation, so I think I must have some basic misunderstanding. No worries, it's just trees.

What are you using to compute your sine and cosine?  Pocket calculators usually take angles in degrees, but something like Excel requires angles to be in radians.  So if you're using a spreadsheet, you might have to convert the angles from degrees to radians.  In Excel you'd have to write that equation like this,

=COS(RADIANS(0.0575))*COS(RADIANS(-91.805))

 

 

[OrbitalManeuvers]

2 hours ago, OhioBob said:

So if you're using a spreadsheet, you might have to convert the angles from degrees to radians.

yup I needed to add this step. thank you again! Took a few tries but managed to remove the groups I wanted!

Spoiler

 

For the curious, here's the dumb spreadsheet I used: https://docs.google.com/spreadsheets/d/1CJX4wOdPLzAqoUWkDCl7QUeU24XuyZ6YDYZ8KWScufs/edit?usp=sharing

 

 

 

[Ocid]

On 11/22/2020 at 5:42 PM, Gordon Fecyk said:

Looks like the save has a fault

So my Krel mission going south (north?) seems to be narrowed down to the save file.

I receive log file entries whenever the wheels lose traction, and this is not restricted to the north pole, or for that matter, restricted to Krel as I've observed this on Aden as well:

[LOG 11:22:34.494] Part wheelMed exited collision with Krel Yp1222222220, but it wasn't in collision count list!
[LOG 11:22:36.060] Part wheelMed exited collision with Krel Yp1222222220, but it wasn't in collision count list!
[LOG 11:22:37.644] Part wheelMed exited collision with Krel Yp1222222220, but it wasn't in collision count list!

I've yet to determine a cause. But I added every add-on one at a time except for Environmental Visual Enhancements, and I'm unable to reproduce the problem with a new save. I can only do it with this save so far.

It might be that this save is a little long in the tooth and it was imported over two KSP versions. I found at least one stock bug post:

This is similar to what I've experienced on Krel, and on Aden during initial tests. This is happening with new rovers built from scratch and cheated to the exact same location as affected ones. EVAs still explode in transitions between sections of terrain affected by this, though strangely they aren't affected if they walk between transitions. Then they just start skating until they hit a different section of terrain, and I lose control unless I can cheat them a few metres above their position.

So my solution seems to be to start a new game and cheat the science back to my current level, unless I can clear or reset a setting in my current save. Maybe clearing a seed value?

[More updates] After trying and failing to revert this save to an earlier version, and also trying and failing to migrate all of the launched craft into another save using Ship Save Splicer (which would lock up the main menu of all things), I poked around the remaining rovers I have scattered around the system. I ran into similar log entries with the rover I left on Pol, but it didn't lose traction. It was also using the Making History retractable wheels though. The other rovers seemed to work, mind you I didn't leave a rover on Edna. Looks like all I can do is push onwards.

If it helps, it looks like new saves on 1.10.1 will be fine. It's just this save that's migrated across three KSP versions might have a few issues.

Sorry for quoting an older post in thread not really relevant to the issue but I've experiencing this issue as well with the wheels and your post came up when looking for a solution to the problem.

For me the issue is present even on a clean stock install. The Ruggedized wheels are the worst culprit they bounce around like they're on some kind of space hopper. Doesn't matter on what planet they're on same behaviour is present just more exaggerated on the likes of the mun cause of lower gravity.

I thought it was an issue with the save as well so loaded up the 1.8.1 install and the problem is present there as well. Just didn't notice because I wasn't using rovers at that point.

Not really sure why I'm responding seeing as not offering a solution just thought I'd chime in and say isn't neccessarily the save thats causing it.

[Gordon Fecyk]

On 12/14/2020 at 10:35 AM, Ocid said:

The Ruggedized wheels are the worst culprit they bounce around like they're on some kind of space hopper.

Actually I first noticed this on Eve, when I started using the ruggedized wheels. My solution was to turn the spring / damper setting to manual and to set it to 1, which seems to set the dampers to behave as though they were on Kerbin with the default setting of Auto. A little more stress on Eve to be sure, but a lot more stable.

[Dafni]

Dear JNSQ fans, lovers and creators,

I have been happily playing my 1.8.1 JNSQ install ever since the release. Needless to say the planet pack is amazing, we all love it and have nothing but thanks and praises for the team.

Now I wonder if I would benefit in any way in updating the install to a more current version of KSP. What is the verdict of the community? Wait for 1.11.1 as is our habit? Look into 1.10.1 for some new KSP framework benefit?

Thank you very much in advance

[panarchist]

3 hours ago, Dafni said:

Dear JNSQ fans, lovers and creators,

I have been happily playing my 1.8.1 JNSQ install ever since the release. Needless to say the planet pack is amazing, we all love it and have nothing but thanks and praises for the team.

Now I wonder if I would benefit in any way in updating the install to a more current version of KSP. What is the verdict of the community? Wait for 1.11.1 as is our habit? Look into 1.10.1 for some new KSP framework benefit?

Thank you very much in advance

JNSQ itself shouldn't have any conflicts, and I'm currently running it on 1.11.0 without issues. I'd see the real answer to your question lies in which mods you have installed. Kopernicus is updated through 1.11, but I believe only on the bleeding edge version - there have been some reported issues, but they look minor. Scatterer has been updated, EVE runs fine as usual. The NFE mod stack has been updated. The USI mod stack has some minor issues being worked through. Kerbalism has been updated without apparent major issues. The WBI stack hasn't been updated, and the components which have dependencies (like Heisenberg) have reported issues under 1.11. You'd be best off looking on those threads to evaluate whether or not to upgrade. The biggest arguments for updating are the performance changes in 1.10.x and the inventory system, and repairs in 1.11. (IMO - there were other good features) None of those have any direct impact on JNSQ.

[OrbitalManeuvers]

3 hours ago, Dafni said:

Wait for 1.11.1 as is our habit?

To echo the previous answer: heck no. I've been using the same JNSQ release in 1.9, 1.10, and 1.11. The "thing" you'll need to keep in mind if you move past 1.8 is the Kopernicus version - which is pretty trivial, since RTB's builds are built with the target KSP version number plainly visible. 

[Dafni]

7 hours ago, panarchist said:

JNSQ itself shouldn't have any conflicts, and I'm currently running it on 1.11.0 without issues. I'd see the real answer to your question lies in which mods you have installed. Kopernicus is updated through 1.11, but I believe only on the bleeding edge version - there have been some reported issues, but they look minor. Scatterer has been updated, EVE runs fine as usual. The NFE mod stack has been updated. The USI mod stack has some minor issues being worked through. Kerbalism has been updated without apparent major issues. The WBI stack hasn't been updated, and the components which have dependencies (like Heisenberg) have reported issues under 1.11. You'd be best off looking on those threads to evaluate whether or not to upgrade. The biggest arguments for updating are the performance changes in 1.10.x and the inventory system, and repairs in 1.11. (IMO - there were other good features) None of those have any direct impact on JNSQ.

 

7 hours ago, OrbitalManeuvers said:

To echo the previous answer: heck no. I've been using the same JNSQ release in 1.9, 1.10, and 1.11. The "thing" you'll need to keep in mind if you move past 1.8 is the Kopernicus version - which is pretty trivial, since RTB's builds are built with the target KSP version number plainly visible. 

Thanks for the insights guys, appreciate it.

Keeping the mod lists in line with my KSP installs is standard operating procedure here. I follow the Kopernicus develpment too. I am just completely out of the loop with the JNSQ news, as the 1.8.1 install just plays and runs very good. Never felt the need to move on with that install.

@panarchist those performance changes in 1.10 you mention,  did they make a noticeable difference for you, on JNSQ?? (if yes, what kind of hardware do you run if I may ask??)

[Ocid]

On 12/21/2020 at 10:07 PM, Gordon Fecyk said:

Actually I first noticed this on Eve, when I started using the ruggedized wheels. My solution was to turn the spring / damper setting to manual and to set it to 1, which seems to set the dampers to behave as though they were on Kerbin with the default setting of Auto. A little more stress on Eve to be sure, but a lot more stable.

Sorry didn't notice your reply. I'll give that a go thanks.

[panarchist]

14 hours ago, Dafni said:

 

Thanks for the insights guys, appreciate it.

Keeping the mod lists in line with my KSP installs is standard operating procedure here. I follow the Kopernicus develpment too. I am just completely out of the loop with the JNSQ news, as the 1.8.1 install just plays and runs very good. Never felt the need to move on with that install.

@panarchist those performance changes in 1.10 you mention,  did they make a noticeable difference for you, on JNSQ?? (if yes, what kind of hardware do you run if I may ask??)

Noticeable, yes. Significant, not sure - for me, the biggest impact on performance was turning off terrain scatters,  and that performance improvement makes everything else not noticeable by comparison. 1.11 seems to feel slighty slower than 1.10 and 1.9, but I haven't done a framerate comparison. It's hard to keep track, since I usually am playing an instance with 65-80 mods. JNSQ + Kerbalism is much slower for reasons I suspect are obvious. ;-) That's not my primary instance of KSP, though - that one is JNSQ+NF

I'm running a 3yo Dell Inspiron 7570 - 1.8Ghz i7, 32GB of RAM, 4GB NVIDIA GeForce MX130. Dual SSD.

[Dafni]

1 hour ago, panarchist said:

Noticeable, yes. Significant, not sure - for me, the biggest impact on performance was turning off terrain scatters,  and that performance improvement makes everything else not noticeable by comparison. 1.11 seems to feel slighty slower than 1.10 and 1.9, but I haven't done a framerate comparison. It's hard to keep track, since I usually am playing an instance with 65-80 mods. JNSQ + Kerbalism is much slower for reasons I suspect are obvious. ;-) That's not my primary instance of KSP, though - that one is JNSQ+NF

I'm running a 3yo Dell Inspiron 7570 - 1.8Ghz i7, 32GB of RAM, 4GB NVIDIA GeForce MX130. Dual SSD.

Hmm, I see. Thank you very much, I appreciate your time.

[antilochus]

Having a blast with this - does anyone have a spreadsheet with orbital characteristics of JNSQ bodies? (like this one for stock.) I can do it manually but just checking.

[OrbitalManeuvers]

10 minutes ago, antilochus said:

Having a blast with this - does anyone have a spreadsheet with orbital characteristics of JNSQ bodies? (like this one for stock.) I can do it manually but just checking.

Genuinely curious ... do you like to know all of this ahead of time? I ask because I'm still kind of yearning for an experience where everything about a solar system has to be discovered by in-game mechanics, like nothing shows in the tracking station until you know X about it, you have to use telescopes, etc. I think there are a couple mods that aim at tackling this (on my ksp to-do list) but I was curious if the complete opposite fits into a particular play style maybe? Or maybe you're just sandboxing and want everything laid out? Curious what you use this much detail for in game.

[antilochus]

41 minutes ago, OrbitalManeuvers said:

Genuinely curious ... do you like to know all of this ahead of time? I ask because I'm still kind of yearning for an experience where everything about a solar system has to be discovered by in-game mechanics, like nothing shows in the tracking station until you know X about it, you have to use telescopes, etc. I think there are a couple mods that aim at tackling this (on my ksp to-do list) but I was curious if the complete opposite fits into a particular play style maybe? Or maybe you're just sandboxing and want everything laid out? Curious what you use this much detail for in game.

Mostly just for basic stuff like budgeting relay hohmann transfers + circularization. I have never played with ResearchBodies so can't really say... I find there are always things you 'discover' e.g. just today how my latest Eve landers sunk into the ocean. I like to know basic characteristics for fuel budgeting because I hate to run out of fuel when spending hours on interplanetary missions especially when running other constraints like comsat or life support.

[PocketBrotector]

25 minutes ago, antilochus said:

Mostly just for basic stuff like budgeting relay hohmann transfers + circularization. I have never played with ResearchBodies so can't really say... I find there are always things you 'discover' e.g. just today how my latest Eve landers sunk into the ocean. I like to know basic characteristics for fuel budgeting because I hate to run out of fuel when spending hours on interplanetary missions especially when running other constraints like comsat or life support.

The CelestialBodies pdf and dV maps included with JNSQ are probably the best resources. Or you could pull raw values directly from the cfg files. I also recommend the transfer window planner in my sig  

[OhioBob]

2 hours ago, antilochus said:

Having a blast with this - does anyone have a spreadsheet with orbital characteristics of JNSQ bodies? (like this one for stock.) I can do it manually but just checking.

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

[antilochus]

Anyone have (attractive) ideas or craft designs for taking tourists to orbit? Without mk1-2 spaceplanes everything looks like a capsule with a mk1 crew tube on top. I haven’t tested mk3 yet.

Edit: also open to any helpful mods (4+ crew capsules?)

Edited January 5, 2021 by antilochus

[Gordon Fecyk]

15 hours ago, antilochus said:

Anyone have (attractive) ideas or craft designs for taking tourists to orbit?

https://kerbalx.com/gordonf/SSTO-Crew-Craft-for-JNSQ-or-other-25x-scale-home-world

Mind you this needs rapiers to work. It's also designed for FAR, but could work with stock aero if you filled all of the wet wings with fuel.

Edited January 5, 2021 by Gordon Fecyk