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

[kerbnub]

Is there an easy explanation for greatly decreased fps after getting close to Minmus in particular? Getting within a few km of Minmus is a much bigger fps hit than usual while physics is running, and landing on a craft with many parts is a slideshow. When on rails, there's no performance decrease. It's only terrible when off rails, and that persists in the scene until I leave Minmus SOI. From a brief Hyperedit test, it doesn't seem to happen around any other bodies. I'm not seeing any error spam in the log.

Running KSP 1.6.1 with JNSQ 0.7, Kopernicus 1.6.1-8, Scatterer and EVE

 

 

[Sigma88]

On 6/24/2019 at 1:23 AM, Jognt said:

With regards to Tweakchutes: its a nice fix for a stock oversight, but I don’t think it’s a good idea to just apply it to everything with a parachute key because:
a: people who are used to the stock behavior will wonder what on earth changed their chutes;
b: mod-added chutes will/can also be affected which would make TweakChutes a ‘bad neighbor’. 

regarding the first issue (people expecting a different behaviour) I think it is actually a point for TweakChutes rather than against them

in stock the atmospheres are too squashed to make anyone incur in a situation where a parachute can fully deploy before semi deploying

so, you always see parachutes semi-deploy and then fully deploy.

JNSQ was designed with different atmospheres in mind, some of them are specifically tuned so that you get very low pressures near the ground.

with this new setup you could argue that people would expect a parachute that has a pressure limit higher than the atmospheric pressure to never deploy.

I think the majority of people would expect the standard behaviour to be the TweakChute one rather than the stock one

 

regarding the second issue, I think that while it is *technically* true, I don't really see a reason for any parachute mod to be affected negatively by this.

 

however, in the spirit of compatibility, here's my new proposed cfg.

Spoiler

@PART:HAS[!MODULE[TweakChute],@MODULE[ModuleParachute]:HAS[#minAirPressureToOpen[*]]]:LAST[JNSQ]
{
    MODULE
    {
        name = TweakChute
        altitudeSliderMin = 50
        altitudeSliderMax = 5000
        altitudeSliderStep = 50
        pressureSliderMin = #$/MODULE[ModuleParachute]/minAirPressureToOpen$
        pressureSliderMax = 0.75
        pressureSliderStep = 0.01
    }
}
@PART:HAS[!MODULE[TweakChute],@MODULE[ModuleParachute]]:LAST[JNSQ]
{
    MODULE
    {
        name = TweakChute
        altitudeSliderMin = 50
        altitudeSliderMax = 5000
        altitudeSliderStep = 50
        pressureSliderMin = 0.01
        pressureSliderMax = 0.75
        pressureSliderStep = 0.01
    }
}

 

as you can see there is now a :HAS[!MODULE[TweakChute] check

this will allow anyone who doesn't want TweakChute to affect their parts to just add this:

Spoiler

MODULE:NEEDS[TweakChute]
{
	name = TweakChute
	enabled = false
}

 

or of course use a patch like this:

Spoiler

@PART:HAS[@MODULE[TweakChute]]:FINAL
{
	!MODULE[TweakChute] {}
}

 

 

Edited June 25, 2019 by Sigma88

[OhioBob]

7 hours ago, Sigma88 said:

regarding the first issue (people expecting a different behaviour) I think it is actually a point for TweakChutes rather than against them

in stock the atmospheres are too squashed to make anyone incur in a situation where a parachute can fully deploy before semi deploying

so, you always see parachutes semi-deploy and then fully deploy.

JNSQ was designed with different atmospheres in mind, some of them are specifically tuned so that you get very low pressures near the ground.

with this new setup you could argue that people would expect a parachute that has a pressure limit higher than the atmospheric pressure to never deploy.

I think the majority of people would expect the standard behaviour to be the TweakChute one rather than the stock one

I wholeheartedly agree with this.  I remember the first time I tested stock parachute behavior on a planet with a very thin atmosphere.  I was like, "why the heck are my parachutes deploying, that shouldn't happen."  When I realized what was happening my first thought was, "that doesn't make any sense."  My expectation prior to the test was that parachutes were going to behave the way they do with TweakChutes.  I was quite surprised by what I saw in the stock behavior.

[1straycat]

After playing around with this a bit, I have to say incredible job to all of you! As someone recently trying to get the ideal setup playing at various scales (2.5x, 3.2x, 6.4x, 10.625x) most of my KSP time, I'd say you've gotten the balance just perfect for a great experience with stock parts. There are some subtleties I've noticed that make it better than any of those rescales. I had thought 2.5x was ideal until I played 3.2x, which was better (but also starting to get dreary timewise) but this scale manages to take the best of both worlds, as while worlds are smaller than 3.2x, the flatter atmosphere height (at 85km, it's less deep than 2.5 or 3.2x) makes for harsher reentries, so your mk1 pod NEEDS a heat shield to survive, which was not the case in either of the above. I'm now struggling to figure out how to reenter a craft holding 3 kerbals in early career without exploding.

It's also a perfect scale/shape for more realistic rockets with stock parts; my assessment generally involves building some test endgame rocket and spaceplane SSTOs and seeing what's possible. A Twin Boar stack can barely SSTO an mk1-3 command pod, and surviving reentry is out of the question. While a mammoth based rocket might have the margins to SSTO a single mk1-3 command pod and return, surviving reentry would probably still be a problem. On the spaceplane side, a stock refueling SSTA (minus Eve, of course, maybe Moho, and dunno about the new Tylo or other new worlds/changes) is much harder but still possible, so my spaceplane love will still be satisfied :D.

I love the trend toward realism graphically; it's especially refreshing not to have to deal with the scatterer artifacts with rescaled worlds, or clouds poking through terrain in rescales. The graphics quality is an obvious upgrade, but the more realistic look with flatter land just looks gorgeous (and that crazy new sunflare), and allows for lower orbits as well, which feels more realistic/majestic too. I haven't explored more than a bit of Mun and Minmus, but love what I've seen.

Overall, extremely well done. Compatibility with all the major mods out of the box is a nice bonus. This is of a quality like the NF mods and Restock. It's so nice to be able to start a career without having to spend a week tweaking and making things compatible/balanced, or with the confidence that major things won't break halfway in, and explore a largely new system while at it.

 

My only question/suggestion for now is why does Kerbin have no rivers? I think they would go along with the realistic design direction while also being very interesting to fly in/around.

[Jognt]

12 hours ago, Sigma88 said:

regarding the first issue (people expecting a different behaviour) I think it is actually a point for TweakChutes rather than against them.
[snip]
regarding the second issue, I think that while it is *technically* true, I don't really see a reason for any parachute mod to be affected negatively by this.however, in the spirit of compatibility, here's my new proposed cfg.

Spoiler

@PART:HAS[!MODULE[TweakChute],@MODULE[ModuleParachute]:HAS[#minAirPressureToOpen[*]]]:LAST[JNSQ]
{
    MODULE
    {
        name = TweakChute
        altitudeSliderMin = 50
        altitudeSliderMax = 5000
        altitudeSliderStep = 50
        pressureSliderMin = #$/MODULE[ModuleParachute]/minAirPressureToOpen$
        pressureSliderMax = 0.75
        pressureSliderStep = 0.01
    }
}
@PART:HAS[!MODULE[TweakChute],@MODULE[ModuleParachute]]:LAST[JNSQ]
{
    MODULE
    {
        name = TweakChute
        altitudeSliderMin = 50
        altitudeSliderMax = 5000
        altitudeSliderStep = 50
        pressureSliderMin = 0.01
        pressureSliderMax = 0.75
        pressureSliderStep = 0.01
    }
}

 

 

Oh I agree 100% that TweakChute behavior makes sense. (stock behavior doesn't, at all).
It's just that there will always be edge cases where an end user uses something in a way it was not intended to do. The scenarios that I can imagine are all in the "k.. whatever floats your boat" range, but they exist nonetheless.

I ran your proposed cfg in my install and MM patches applied went from 6075 to just 5119!
No noticeable loading time impact that I can tell, but it's a lot cleaner and warms my heart  

One question though: Why the second filter? Are there moduleParachute's out there without a minAirPressureToOpen key?

Edited June 25, 2019 by Jognt

[OhioBob]

3 minutes ago, Jognt said:

One question though: Why the second filter? Are there moduleParachute's out there without a minAirPressureToOpen key?

I can't imagine there being any ModuleParachute out there without minAirPressureToOpen, but better safe than sorry.  It's just a catch all precaution.

[OhioBob]

38 minutes ago, 1straycat said:

… so your mk1 pod NEEDS a heat shield to survive ...

My experience playing at this scale is that for LKO reentries, a heat shield is required, but not ablator.  The temperature will generally spike above the limit of a command pod, but will stay below the 3300 K limit of a heat shield.  Having ablator will lower the temperature of the heat shield, but there's no need for that unless there's a chance we'll exceed the maximum temperature without it.

[Sigma88]

2 hours ago, Jognt said:

Are there moduleParachute's out there without a minAirPressureToOpen key?

if you create a new chute and don't specify the value, ksp will apply the default which is 0.01

it's to make sure the behaviour of the cfg is consistent and not different depending on whether your part has the value explicitly defined or not

[JadeOfMaar]

The idea for this has been open for a while but it's time I made a thread for it and made it clearly known. Players are invited to get creative with our biome maps and supply something to find other than just Poles, Highlands, Lowlands...

 

[vossiewulf]

Like most players, I tend to only post in mod threads when I have a problem, but a note I just sent to Jade reminded me that's a bad habit.

I'd like to say as a reasonably-experienced KSP player that I'm really enjoying JNSQ. For me at least, you have hit a sweet spot where it's considerably more challenging than stock, without going full gonzo RO, and it's obvious the team sweated the details as so far everything is very polished. There's of course no single planet pack or scale that can be said to be best, but I can say that the team has done an extremely good job of creating a coherent design and executing it really well. I think it's going to be quite popular with all players who have been through a stock game or three and are looking for a greater challenge.

In fact if it just had a moon called Vossieworld, made entirely out of thick-cut bacon, it would be danged-near perfect.

So thanks from me and all the other people who forget to post anything but hey it's broken again fix it!

[vossiewulf]

So enough of that, hey it's broken again fix it!

Are there any known issues with Waypoint Manager? I'm seeing it work except for the ETAs, which seem to be pretty confused. While flying dead at the target, and this is clear as the distance to target is spinning down at the expected rate, the ETA will spin down like you're flying 10 times faster than you are, then it stops and climbs for a while, and this will loop over and over through a flight. It's hardly game breaking, but something is confused and it seems likely that would be an issue of not all of someone's code getting the memo about the non-stock scale.

[4x4cheesecake]

2 hours ago, vossiewulf said:

I'm seeing it work except for the ETAs, which seem to be pretty confused. While flying dead at the target, and this is clear as the distance to target is spinning down at the expected rate, the ETA will spin down like you're flying 10 times faster than you are, then it stops and climbs for a while, and this will loop over and over through a flight.

ETA will be calculated multiple times per second so if you don't fly at a constant speed, it will "jump" around like you describe but will work fine while orbiting or using an autopilot in atmosphere.

[vossiewulf]

6 hours ago, 4x4cheesecake said:

ETA will be calculated multiple times per second so if you don't fly at a constant speed, it will "jump" around like you describe but will work fine while orbiting or using an autopilot in atmosphere.

Thanks, good it's not broken. I used to use Waypoint Manager quite a bit, wonder why I didn't remember/know that.

[panarchist]

What's the reason for deleting settings.cfg on an upgrade? Is that a hard requirement? The main reason I ask is because restoring all the settings is kind of a pain - it's not just graphics as the pdf states, but also all of the controller mappings. I wouldn't expect that the settings.cfg would impact anything, unless it's a need to reset the entire graphics environment to default. If that's the case, then I should be able to just remove the file, start KSP, get a generic config when I load the game, and then copy in my old settings.cfg, right?

[jefferyharrell]

@panarchist Terrain detail settings are stored in settings.cfg. These settings changed between JNSQ versions, so you need to delete settings.cfg and let the game create a new one, then apply all your settings. Don't just copy your old settings.cfg file back, because that defeats the whole purpose of deleting it in the first place.

[BigFatStupidHead]

Just now, jefferyharrell said:

@panarchist Terrain detail settings are stored in settings.cfg. These settings changed between JNSQ versions, so you need to delete settings.cfg and let the game create a new one, then apply all your settings. Don't just copy your old settings.cfg file back, because that defeats the whole purpose of deleting it in the first place.

Would it be enough to set the terrain detail to a different setting and, after a save or two, back again?

[panarchist]

1 minute ago, jefferyharrell said:

@panarchist Terrain detail settings are stored in settings.cfg. These settings changed between JNSQ versions, so you need to delete settings.cfg and let the game create a new one, then apply all your settings. Don't just copy your old settings.cfg file back, because that defeats the whole purpose of deleting it in the first place.

Ok, thanks - that's what I needed to know. I'm going to have to manually merge settings files each update.

[Galileo]

1 hour ago, panarchist said:

What's the reason for deleting settings.cfg on an upgrade? Is that a hard requirement? The main reason I ask is because restoring all the settings is kind of a pain - it's not just graphics as the pdf states, but also all of the controller mappings. I wouldn't expect that the settings.cfg would impact anything, unless it's a need to reset the entire graphics environment to default. If that's the case, then I should be able to just remove the file, start KSP, get a generic config when I load the game, and then copy in my old settings.cfg, right?

Its a pretty hard requirement for the latest update, unless you enjoy crap performance.

JNSQ and Kopernicus write to your settings cfg. They adds the terrain detail settings that you see in the main menu (JNSQ_Low/Medium/High) which definitely impact performance. What you can do is delete all the JNSQ terrain nodes in the settings cfg to avoid deleting the entire thing and just reselect your prefered terrain detail settings upon the start of a new game. For those that have no clue how to do that, it easier for them to delete the entire cfg and rebuild their settings. We don't have time to hold users hands, and that's really why we ask people to just rebuild their settings, especially for this update. Beyond this update, it shouldn't be necessary.

5 minutes ago, BigFatStupidHead said:

Would it be enough to set the terrain detail to a different setting and, after a save or two, back again?

No because the old settings nodes persist even when you choose another terrain detail setting. The nodes need to be removed or you have to delete the settings cfg. 

Edited June 26, 2019 by Galileo

[BigFatStupidHead]

7 minutes ago, Galileo said:

Its a pretty hard requirement for the latest update, unless you enjoy crap performance.

JNSQ and Kopernicus write to your settings cfg. They adds the terrain detail settings that you see in the main menu (JNSQ_Low/Medium/High) which definitely impact performance. What you can do is delete all the JNSQ terrain nodes in the settings cfg to avoid deleting the entire thing and just reselect your prefered terrain detail settings upon the start of a new game. For those that have no clue how to do that, it easier for them to delete the entire cfg and rebuild their settings. We don't have time to hold users hands, and that's really why we ask people to just rebuild their settings, especially for this update. Beyond this update, it shouldn't be necessary.

No because the old settings nodes persist even when you choose another terrain detail setting. The nodes need to be removed or you have to delete the settings cfg. 

Ah, that would explain a lot. Thanks!

[panarchist]

5 minutes ago, Galileo said:

Its a pretty hard requirement for the latest update, unless you enjoy crap performance.

JNSQ and Kopernicus write to your settings cfg. They adds the terrain detail settings that you see in the main menu (JNSQ_Low/Medium/High) which definitely impact performance. What you can do is delete all the JNSQ terrain nodes in the settings cfg to avoid deleting the entire thing and just reselect your prefered terrain detail settings upon the start of a new game. For those that have no clue how to do that, it easier for them to delete the entire cfg and rebuild their settings. We don't have time to hold users hands, and that's really why we ask people to just rebuild their settings, especially for this update. Beyond this update, it shouldn't be necessary.

No because the old settings nodes persist even when you choose another terrain detail setting. The nodes need to be removed or you have to delete the settings cfg. 

Good to know, thanks. Not looking for hand-holding, I *am* your target audience - technically astute, former KSP QA guy, playing KSP 6 years, etc, etc. Just looking for the specific info since I expect I'm not the only one with a heavily-altered settings.cfg. Also looking forward to the performance improvements, I've been keeping tabs on the thread, but not every day. Thanks for taking the time to add the detail, I really appreciate the lengths you go to when keeping the community informed.

[Galileo]

1 minute ago, panarchist said:

Good to know, thanks. Not looking for hand-holding, I *am* your target audience - technically astute, former KSP QA guy, playing KSP 6 years, etc, etc. Just looking for the specific info since I expect I'm not the only one with a heavily-altered settings.cfg. Also looking forward to the performance improvements, I've been keeping tabs on the thread, but not every day. Thanks for taking the time to add the detail, I really appreciate the lengths you go to when keeping the community informed.

Oh, I know, and I'm not directing that at you. I was just explaining our thought process when asking people to do something as inconvenient as deleting their settings cfg and resetting it. It may not be ideal, but it keeps us from having to tell people 1000 times how to just delete the nodes. 

[panarchist]

2 minutes ago, Galileo said:

Oh, I know, and I'm not directing that at you. I was just explaining our thought process when asking people to do something as inconvenient as deleting their settings cfg and resetting it. It may not be ideal, but it keeps us from having to tell people 1000 times how to just delete the nodes. 

Exactly - can relate.

Are there any issues using DX11 with JNSQ? I just crashed the new version hard, but I'm running Textures Unlimited, so there might be issues there. Not going to report anything unless I have difficulty on dx9 with no additional mods. I typically run with 60+ mods, and while I didn't have issues before the performance improvements, I also suspect not all 61 mods are updated for 1.7.1.

[Galileo]

1 minute ago, panarchist said:

Exactly - can relate.

Are there any issues using DX11 with JNSQ? I just crashed the new version hard, but I'm running Textures Unlimited, so there might be issues there. Not going to report anything unless I have difficulty on dx9 with no additional mods. I typically run with 60+ mods, and while I didn't have issues before the performance improvements, I also suspect not all 61 mods are updated for 1.7.1.

I run dx11 pretty exclusively, and havent had any issue besides what is known regarding that. I havent used TU with JNSQ yet but I see people talk about using it with JNSQ quite often so I dont suspect there are any issues

[sturmhauke]

Speaking as a professional developer who is also starting to tinker with KSP mods, messing around with raw .cfg files can be tedious and error prone. If nuking it and letting the game rebuild it is an option, you really should just do that.

[Jognt]

On 6/26/2019 at 1:08 AM, Sigma88 said:

if you create a new chute and don't specify the value, ksp will apply the default which is 0.01

it's to make sure the behaviour of the cfg is consistent and not different depending on whether your part has the value explicitly defined or not

Fair enough.

I took the liberty to give the SolarPanels.cfg a similar treatment. Just the change in these two .cfg files cut down the amount of patches by 30%. (~6000 to ~4000). Better, faster, safer. What's not to love?

Here's what I went with:

@PART:HAS[@MODULE[ModuleDeployableSolarPanel]]:BEFORE[Kopernicus]
{
    @MODULE[ModuleDeployableSolarPanel]
    {
        useKopernicusSolarPanels = false
    }
}

Edit: I see you guys already committed a similar change 2 days ago, cheers . It's in a different timing than before though.
The old CFG had "BEFORE[Kopernicus]" but the new solarpanels has "LAST[JNSQ]"; Guessing that's by accident?

 

4 hours ago, panarchist said:

Exactly - can relate.

Are there any issues using DX11 with JNSQ? I just crashed the new version hard, but I'm running Textures Unlimited, so there might be issues there. Not going to report anything unless I have difficulty on dx9 with no additional mods. I typically run with 60+ mods, and while I didn't have issues before the performance improvements, I also suspect not all 61 mods are updated for 1.7.1.

The only issue I had (besides the usual blue VAB icons without TU, the disappearing reentry effects, and the grainy texture filtering problem) was that for some reason the ground textures looked like a totally even color. The ground around KSC was like a green 'area fill' tool was used. This went away when I returned to Dx9.

Edited June 27, 2019 by Jognt