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

[MulDoom]

I love you guys.

[sturmhauke]

2 hours ago, OhioBob said:

Announcement - Upcoming Change

Please be advised that the next version of JNSQ will be making changes to the orbit of Minmus.  While this revision is targeted primarily at users of the mod Principia, some changes will affect everyone...

If any players want to implement this change now and not wait for the next JNSQ release, then just copy the following patch to a .cfg file and save it inside your Gamedata/JNSQ folder.

This doesn't affect me, but I'm curious: if you have satellites in orbit around Minmus and then apply this patch, what happens?

[Zorg]

7 hours ago, Iso-Polaris said:

May I ask which mod are those parts (specifically solar and antenna) come from?

Everything on that craft except for the truss structure are from Bluedog Design Bureau. It has some nice probe parts (these parts are based on the Ranger probes https://en.wikipedia.org/wiki/Ranger_program ) but mainly contains historical American rockets.

Spoiler

 

 

[JadeOfMaar]

7 hours ago, sturmhauke said:

This doesn't affect me, but I'm curious: if you have satellites in orbit around Minmus and then apply this patch, what happens?

They hold their positions in Minmus' SOI. In KSP, moving a planet does not mean ripping it out from everything orbiting it.

[OhioBob]

7 hours ago, sturmhauke said:

This doesn't affect me, but I'm curious: if you have satellites in orbit around Minmus and then apply this patch, what happens?

As @JadeOfMaar said, anything orbiting or landed on Minmus will not be affected.  When Minmus moves, those vessels move with in.  But anything you might have en route will be affected.  When a celestial body is relocated, the course of vessels outside its sphere of influence do not change, so they'll no longer intercept the target.  A course correction will be require to reacquire the target.  It is always best to let vessels reach their destinations before installing an upgrade that relocates a celestial body.  In the case of Minmus the travel time is only a few days, so it's unlikely you would upgrade in the middle of a flight.  But if the relocated body is a planet, where travel times can be long, this is an issue you may need to consider.

[Galileo]

7 hours ago, sturmhauke said:

This doesn't affect me, but I'm curious: if you have satellites in orbit around Minmus and then apply this patch, what happens?

The changes to Minmus coming up will affect you, though if you have vessels landed there, as I had to recreate it’s texture. It will be worth it though!

[RocketSquid]

This looks really interesting. I’ll definitely try it out when I finish up with my current save in... probably about twelve and a half years. 

[sturmhauke]

Well I was planning on starting a new game with this mod, rather than try to import a current one. I mostly play one-off missions in sandbox anyway, and my career save dates back to 1.3.1.

[Lucius]

3 hours ago, Galileo said:

The changes to Minmus coming up will affect you, though if you have vessels landed there, as I had to recreate it’s texture. It will be worth it though!

Oooo now thats a good tease, can't wait to see!

[Jesusthebird]

On 5/30/2019 at 1:00 PM, OhioBob said:

 

 

 

I havnt seen this style of dvmaps before. I dig it!!

Edited June 4, 2019 by Jesusthebird

[jefferyharrell]

I am in love with this mod. Absolutely in love with it. I've started a new game with Research Bodies installed and deliberately avoided looking at any screen shots or anything so I can discover the solar system blind.

Thought I'd share something I'm working on. I've created a version of my kOS ascent program that's tuned for JNSQ. It's still very much a work in progress, but at the moment it can put an upper stage into a 95 × 90 km orbit via direct ascent for a hair over 5,000 m/s. (Direct ascent meaning no coast phases except during stage separation.) The first stage needs to have a sea-level Δv of about 3,500 m/s and a liftoff TWR of 1.5, and the upper stage needs an initial TWR of about 1.2 and a vacuum Δv of about 1,500 m/s for a little maneuvering margin. I'm still working on turning things. In the screenshot below, the circularization maneuver at apoapsis to make it a 95 × 95 orbit was 3.1 m/s. It's not the most efficient ascent program it's possible to imagine, but it has the virtue of being consistent.

https://github.com/jefferyharrell/YAKAP-JNSQ

Now for a question: Prior to JNSQ, I used to play stock with a little Kopernicus config that made the sunlight brighter. It looked like this:

@Kopernicus:AFTER[Kopernicus]
{
    @Body[Sun] 
    {
        @ScaledVersion
        {
            Light
            {
                sunlightIntensity = 1.5
                scaledSunlightIntensity = 1.5
                IVASunIntensity = 1.5
            }
        }
    }
}

This trick obviously doesn't work with KNSQ, but I was wondering if there's a trick that will? A cursory Google search didn't turn up any useful info on the intensity curve part of the Kopernicus config, so I don't know what the values are or which ones to change.

Thanks for the fantastic, fantastic mod.

[OhioBob]

@jefferyharrell, JNSQ uses sunlight intensity curves that decrease illumination with increasing distance from the sun.  The factors used in your patch produce even illumination regardless of distance.  They can still be used but are a bit outdated.  To get them to work you probably need to delete the curves so the fixed parameters take over.  I recommend trying this:

Spoiler

@Kopernicus:AFTER[JNSQ]
{
    @Body[Sun] 
    {
        @ScaledVersion
        {
            Light
            {
                !IntensityCurve {}
                !ScaledIntensityCurve {}
                !IVAIntensityCurve {}
                sunlightIntensity = 1.5
                scaledSunlightIntensity = 1.5
                IVASunIntensity = 1.5
            }
        }
    }
}

 

 

[Galileo]

3 hours ago, Lucius said:

Oooo now thats a good tease, can't wait to see!

Just check the screenshot link in the op

[jefferyharrell]

@OhioBob Thanks very much, but is there a better way? What I mean is, your config files have intensity curves that define brightness as a function of distance. Can I MM-patch those curves so that each point has a value that's 1.5 × the value in your config file? I don't want anything fancy; I can do the arithmetic myself, obviously. I just don't know which numbers in the config file's intensity curve section correspond to what.

I should emphasize that this is strictly a cosmetic thing just for me. I play with KS3P, so all I'm going for here is something that'll look sexier on my screen, not some big global change that affects everybody.

[OhioBob]

 

2 hours ago, Jesusthebird said:

I havnt seen this style of dvmaps before. I dig it!!

Glad you like it.  That's our own design.  I've always found the traditional subway style a bit of a pain to use, so we wanted to do something different.  Our hope is that this one will be easier to follow.
 

11 minutes ago, jefferyharrell said:

@OhioBob Thanks very much, but is there a better way? What I mean is, your config files have intensity curves that define brightness as a function of distance. Can I MM-patch those curves so that each point has a value that's 1.5 × the value in your config file? I don't want anything fancy; I can do the arithmetic myself, obviously. I just don't know which numbers in the config file's intensity curve section correspond to what.

I should emphasize that this is strictly a cosmetic thing just for me. I play with KS3P, so all I'm going for here is something that'll look sexier on my screen, not some big global change that affects everybody.

You still need to delete the curves as I showed you.  Then just add the curves back with new numbers.  The first number in each key is distance, don't change that.  The second number is intensity, multiply those by 1.5.  The third and fourth numbers are slopes, they too get multiplied by 1.5.
 

Edited June 4, 2019 by OhioBob

[jefferyharrell]

@OhioBob PERFECT! Exactly what I wanted to know! Thank you so much!

[New Horizons]

What do you guys think about using Real Fuels Stockalike here? Might it be too overpowered and not really needed because of the sweet rescale of this mod anyway?

[panarchist]

On 5/30/2019 at 4:41 PM, Galileo said:

Well, Make a separately install!

Or use GPP Secondary and have... BOTH! ;-)

[JadeOfMaar]

7 minutes ago, New Horizons said:

What do you guys think about using Real Fuels Stockalike here? Might it be too overpowered and not really needed because of the sweet rescale of this mod anyway?

What's the purpose of RF Stockalike? I know the name but that's it. Anything that's supposed to make RSS playable is not needed in scales lower than 3.2x. If you like RSS, then you'll feel at home with stock engines, largely un-tuned, on 2.5x or 2.7x.

[Lucius]

1 hour ago, Galileo said:

Just check the screenshot link in the op

Oof forgot to turn my brain on apparently.

 

Also, for the whole team, i have a weirdly specific question thats out of pure curiosity. Back in the days of say, 0.25, the big debate was that the kerbin system was properly sized for 6.4x systems. There was a lot of debate that this was a figure pulled out of people's behind and there was no real numbers to solidly back such a statement.

How did you come to decide that 2.5x/2.7x was "just right" for your planet sizing? What was the thought process, what numerics did you use, what comparisons did you make, if you don't mind i just really want to know how the system "came to be" that way, i guess.

 

Also, considering dropping a "rescale" preconfig of 2x onto this system just to see how it handles, has anyone else tried such a thing? Found it enjoyable or not?

[OhioBob]

23 hours ago, Lucius said:

How did you come to decide that 2.5x/2.7x was "just right" for your planet sizing? What was the thought process, what numerics did you use, what comparisons did you make, if you don't mind i just really want to know how the system "came to be" that way, i guess.

I was not alone in coming to the conclusion that 2.5-ish is about right, but I was one of the early proponents of it.  My main goal was to find a scale that used unmodified stock parts, but felt and looked more lifelike in the design of the rockets needed to achieve orbital flight, interplanetary flight, etc.  One of my objectives was no SSTO.  If SSTO was so easy to achieve, we'd have it by now in real life.  I wanted it necessary to use at least two stages to get to orbit, and three stages to go interplanetary.  I just started looking at the delta-v requirements at different scales and concluded that 2.5x was about the minimum needed to force players into these multi-stage configurations.

Another thing I did was look at some real life rockets and estimated what delta-v they could achieve if they had engine and tank mass ratios comparable to those in stock KSP.  My calculations came out to around 5000 m/s, which is about what it takes to get to orbit in KSP at a scale of 2.5x.

So both methods pointed to the same answer -- about 2.5x.

Of course thinking of things as 2.5x, 6.4x, or whatever seems backwards to me.  Real life is the norm, not KSP.  Real life isn't 10x scale, real life is 1x.  KSP is 1/10th scale (actually closer to 1/11th).  So when we think about it that way, we find that 2.5x is close to 1/4 real scale.  1/4 scale just makes a whole lot of sense when you stop to think about it.  For instance, when distances and radii are factored by 1/4, orbital periods and delta-v requirements becomes exactly 1/2.  The math just works beautifully.

1/4 real scale is actually about 2.7x stock scale, though the difference between 2.5x and 2.7x is small.  And besides, before 2.5x became a thing, many people played 3.2x.  So 1/4 real scale falls nicely between 2.5 and 3.2.
 

Edited June 5, 2019 by OhioBob

[The-Doctor]

the sunflare alone makes it 100% amazing

[Jognt]

This looks gorgeous! One question though:
How is this set up with Realistic Resources?

Reason I ask is because I try to avoid having to deal with so many resources that my head starts spinning.. (and some of the images in the RR thread made my head spin)
Can I *plonk* this into GameData and build big rockets, or do I need to get a degree in chemistry first?

Edited June 5, 2019 by Jognt
Hmm.. That's actually two questions..

[Quoniam Kerman]

After saves misshaps (my mistakes) making my 1.7 OPM game a nightmare, I decided to screw it and put JNSQ instead (I have 3 other versions of KSP with OPM to play with). It's beautiful.

Yet it lacks something, Lindor's moons are not as varied as were Sarnus' and secondly, will you add Final Frontier achievement ribbons for JNSQ new planets?

Also, why adding an atmosphere on Tylo? Because it would become too hard to land on with 2.7x scale?

[JadeOfMaar]

6 minutes ago, Jognt said:

This looks gorgeous! One question though:
How is this set up with Realistic Resources?

It simply is set up?

The setup is such that certain combinations of resources only happen when X planet or Y moon is a certain class (like rocky, metallic, icy...). You can ignore them and deal with Ore as usual but Ore will be harder to find because Ore, as it is, is the most abstract of resources, and seasoned players, whom JNSQ targets, are more likely (or I expect them) to want to use the more specialized resources instead of it.

Such an abstract resource shouldn't be (afaik) as prominent in a realistic space as stock makes it out to be. But it is so abundant as part of what makes KSP easy and playable when you're new to KSP or a basic player (no offense intended).

You can simply remove Realistic Resources if you want Ore everywhere and can't stand the surface scanner and atmo variometer being loaded with resource readings. For more information:

2 minutes ago, Quoniam Kerman said:

Also, why adding an atmosphere on Tylo? Because it would become too hard to land on with 2.7x scale?

Tylo has an atmosphere because by @OhioBob's logic (the man knows his Physics), it very likely should have one and should never be as big and massive as it is in stock (see: Jool, Laythe and Tylo all having the same amount of gravity and not being a semi-believable binary/trinary group of dwarf stars).

If you're looking for a challenge planet, look to Eve and Nara.

Final Frontier ribbons? Hmm...