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

[OhioBob]

1 hour ago, Jognt said:

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?

Kopernicus' solar panel patch has FINAL, so it going to run at the end regardless, so BEFORE[Kopernicus] isn't needed.  Using LAST[JNSQ] assures that our patch runs after any mods that might add solar panels.

It goes like this:

1)  All solar panel parts are added.
2)  *LAST*  JNSQ adds "useKopernicusSolarPanels = false" to all ModuleDeployableSolarPanel.
3)  *FINAL*  KopernicusSolarPanel is not applied because of #2 above.

 

[vossiewulf]

8 hours ago, sturmhauke said:

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.

You haven't even begun to grasp the pulling teeth without novacaine nature of KSP modding, it's easily the most difficult workflow I've experienced. By the time I was halfway through, I wouldn't have been surprised if the next instruction had said "now sacrifice a green chicken when the Mun is at periapsis". I'm honestly amazed at how much has been achieved under such an unfriendly framework.

[Norcalplanner]

Just thought I'd share a dramatically lit picture of a probe ascending from an Exotic Crater on Mun: 

[vossiewulf]

I know Kerbal Konstructs isn't supported, but does it work with JNSQ? I never thought much about KK but I juat saw those launch pads by Tundra and man those would be fun to use.

[Galland1998]

I have been able to use Tundras mod as part of KSC without any issue. 

[Jognt]

8 hours ago, OhioBob said:

Kopernicus' solar panel patch has FINAL, so it going to run at the end regardless, so BEFORE[Kopernicus] isn't needed.  Using LAST[JNSQ] assures that our patch runs after any mods that might add solar panels.

It goes like this:

1)  All solar panel parts are added.
2)  *LAST*  JNSQ adds "useKopernicusSolarPanels = false" to all ModuleDeployableSolarPanel.
3)  *FINAL*  KopernicusSolarPanel is not applied because of #2 above.

 

I really wouldn’t let whether or not the patch works depend on another mod’s poor ordering choice. Though even if Kopernicus were to go LAST, it’d still be after LAST[JNSQ]. So whatever floats your boat.

Im surprised by the thought that goes into making sure your patches go through while seemingly counting on everyone else to not change. Forward-thinking compatibility it is not. 

Not to mention the fact that for this patch there’s no reason to go LAST in the first place. It’ll work fine, until it doesn’t.

I’ll stop wasting both of our time now. 

Edited June 27, 2019 by Jognt

[Sigma88]

11 hours ago, Jognt said:

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?

we used :LAST for the same reason we used it in the parachute cfg. bob had used :BEFORE[Kopernicus] because he was assuming Kopernicus applied its patch at :FOR[Kopernicus] however the kopernicus patch is applied at :FINAL allowing us to use :LAST

[OhioBob]

1 hour ago, Jognt said:

I really wouldn’t let whether or not the patch works depend on another mod’s poor ordering choice. Though even if Kopernicus were to go LAST, it’d still be after LAST[JNSQ]. So whatever floats your boat.

Im surprised by the thought that goes into making sure your patches go through while seemingly counting on everyone else to not change. Forward-thinking compatibility it is not. 

Not to mention the fact that for this patch there’s no reason to go LAST in the first place. It’ll work fine, until it doesn’t.

Something that's BEFORE, FOR or AFTER goes alphabetically.  So if we used BEFORE[Kopernicus], our patch would be applied to any ModuleDeployableSolarPanel added by a mod that comes alphabetically before "Kopernicus", but would not be applied to any mod that comes alphabetically after "Kopernicus".  By using LAST we let all the parts mods go alphabetically before us.  So a mod that adds a solar panel using FOR[XYZ] gets patched, as it should.  The Kopernicus patch uses FINAL, so it comes after LAST.  This seems to me like the most logical way to sequence things.  I really don't understand what you are complaining about.

[Jognt]

1 hour ago, Sigma88 said:

we used :LAST for the same reason we used it in the parachute cfg. bob had used :BEFORE[Kopernicus] because he was assuming Kopernicus applied its patch at :FOR[Kopernicus] however the kopernicus patch is applied at :FINAL allowing us to use :LAST

That's my point your logic is sound if you assume Kopernicus will keep using FINAL. Your patch relies on another mod not following a best practice. So it'll work as long as that mod does not follow best practice.

I agree that it'll work perfectly fine as long as that is the case. The reason I'm upset over it is because just like the other FINALs the thought process behind it doesn't give much consideration to the use case of other mods wanting to overwrite your changes or of other mods changing their ways. I'd throw it into AFTER[JNSQ] as it would have the same effect yet give more room to be superseded.

It may very well be my autistic perfectionism at play here, so I'll drop it as I realize not everyone is as OCD as I can be. (ask JadeOfMaar, I know I can be annoying )

I will just leave this one plea here: Please put serious consideration into using dependencies/recommendations instead of bundles for stuff like RR, EVE/Scatterer configs and other things.
I've seen a lot of 'modpacks' go wrong with that, and though I appreciate your enthusiasm to finetuning the exact experience you wish to deliver, it reminds me a lot of those packs.

Oh, and after all my complaints, here's something else I really mean: Thank you for JNSQ, it's gorgeous and that sunflare coming over the horizon just before reentry is breathtaking.

Edited June 27, 2019 by Jognt

[Sigma88]

If you have problems with kopernicus using final you'll have to take that to thomas

however I would suggest you to avoid that since thomas is pretty burned out and this might be the last drop

 

you don't want to be the guy that killed kopernicus, the backlash would be extremely harsh

 

[OhioBob]

18 minutes ago, Jognt said:

That's my point your logic is sound if you assume Kopernicus will keep using FINAL. Your patch relies on another mod not following a best practice. So it'll work as long as that mod does not follow best practice.

Our patch is written to work with the current conditions, why would we do anything else?  If the conditions change, we'll adapt as necessary.

What change do you suggest Kopernicus make?  It can't use FOR[Kopernicus] because it will miss patching any mods that come after it.  It could use LAST instead of FINAL.  But if it did that, LAST[JNSQ] still comes before LAST[Kopernicus], so we're still OK.

[Galland1998]

I know using the non official release version of a mod is a "use at your own risk" proposition, but I loaded up a version of the master version of the JNSQ mod from the github.  The github annotation on the master version of JNSQ indicatated that one of the last things changed was a the solar panel config file.  When I loaded up the game that config the module manager showed it as an error during the boot up process.  In a test save I launched a rocket and at least of that one launch the deploy-able solar panel seemed to deploy correctly and generate power correctly.

[sturmhauke]

2 hours ago, Jognt said:

That's my point your logic is sound if you assume Kopernicus will keep using FINAL. Your patch relies on another mod not following a best practice. So it'll work as long as that mod does not follow best practice.

This is where programming idealism runs afoul of the real world. As I understand it, Kopernicus is a major dependency for all or nearly all planetary mods. While you might have valid complaints about the way Kopernicus does things, if you are using it as a dependency you have to make sure your mod works correctly with it. Sometimes that means doing things in a nonstandard way.

[OhioBob]

54 minutes ago, Galland1998 said:

I know using the non official release version of a mod is a "use at your own risk" proposition, but I loaded up a version of the master version of the JNSQ mod from the github.  The github annotation on the master version of JNSQ indicatated that one of the last things changed was a the solar panel config file.  When I loaded up the game that config the module manager showed it as an error during the boot up process.  In a test save I launched a rocket and at least of that one launch the deploy-able solar panel seemed to deploy correctly and generate power correctly.

The solar panel config had a minor syntax error.  We unloaded a correction a few minutes later.  You just have lousy timing.
 

Edited June 27, 2019 by OhioBob

[Jognt]

35 minutes ago, sturmhauke said:

This is where programming idealism runs afoul of the real world. As I understand it, Kopernicus is a major dependency for all or nearly all planetary mods. While you might have valid complaints about the way Kopernicus does things, if you are using it as a dependency you have to make sure your mod works correctly with it. Sometimes that means doing things in a nonstandard way.

I think you've summarized it better than I ever could. Thank you.

 

2 hours ago, OhioBob said:

Our patch is written to work with the current conditions, why would we do anything else?  If the conditions change, we'll adapt as necessary.

What change do you suggest Kopernicus make?  It can't use FOR[Kopernicus] because it will miss patching any mods that come after it.  It could use LAST instead of FINAL.  But if it did that, LAST[JNSQ] still comes before LAST[Kopernicus], so we're still OK.

It's this "in a perfect world it should be X" I tend to get caught up in. My apologies for that. I didn't mean to imply Kopernicus changes, though a LAST would satisfy my inner "everything is perfect", it wouldn't make much (if any) difference in the real world.

 

[Galland1998]

So it looks like in the new-ish master versing on JNSQ you boosted the power of antennas by 4x as a default.  In earlier posts you recommended pushing the DSN power to 16x and leave antenna power at 1x.  Any recommendation on what commnet setting we should be using to get the designed intent?

[OhioBob]

27 minutes ago, Galland1998 said:

So it looks like in the new-ish master versing on JNSQ you boosted the power of antennas by 4x as a default.  In earlier posts you recommended pushing the DSN power to 16x and leave antenna power at 1x.  Any recommendation on what commnet setting we should be using to get the designed intent?

Originally we recommended 4x antenna range and 4x DSN.  Unfortunately the bug we've discovered doesn't allow you to change the range in the difficulty settings.  (You can change it, but you run the risk of the bug biting you.)  As a stop gap we recommended 16x DSN, but that's not a particularly desirable solution either.  So what we've decided to do for the next version is bump the antenna range 4x using a MM patch.  And for the DSN modifier we're recommending 4x, which the player must adjust him/herself in the game settings.  We'd prefer to leave both settings in the hands of the player, but this is the best intermediate solution we could come up with to work around the bug.  Hopefully Squad will eventually fix the problem and we can go back to making antenna range just a recommendation.

Here's what the new instructions will say:

Quote

When starting new saves under JNSQ, we advise that you enter Difficulty Settings and raise the DSN modifier to 4x. JNSQ applies a patch to increase antenna range by 4x, so leave the range modifier at 1 (changing it triggers a bug that may prevent science transmission).

 

Edited June 27, 2019 by OhioBob

[vossiewulf]

8 hours ago, Galland1998 said:

I have been able to use Tundras mod as part of KSC without any issue. 

Thanks Galland.

[Jognt]

Re: JNSQ Performance.

I just visited the Mun where I had the usual yellow clock/FPS issues. On Rocketology's stream I heard it was due to the scatter (which I have set to 30% because of that) but while flying Valentina around with her EVA pack I noticed that the clock went green (and FPS recovered) whenever I was ~200-300m away from the ship.

If the problem disappears when the ship is packed, is it really the scatter?

Edit: Log didn't show anything happening.

Edited June 27, 2019 by Jognt

[Galileo]

50 minutes ago, Jognt said:

Re: JNSQ Performance.

I just visited the Mun where I had the usual yellow clock/FPS issues. On Rocketology's stream I heard it was due to the scatter (which I have set to 30% because of that) but while flying Valentina around with her EVA pack I noticed that the clock went green (and FPS recovered) whenever I was ~200-300m away from the ship.

If the problem disappears when the ship is packed, is it really the scatter?

Edit: Log didn't show anything happening.

Yes it was really the scatter. 0.7 fixed the Scatter performance issue. If you are experiencing lag with ships now, it’s not JNSQ.

[Gordon Fecyk]

Mods needed for ISRU?

Without giving any spoilers away, what are the minimum additional add-ons needed to make ISRU work for producing fuels? Is it just Community Resource Pack, or will other items be needed?

I'm only interested in producing fuels in-situ, like stock, but within Rational Resources and JNSQ constraints.

[Pleb]

1 hour ago, Gordon Fecyk said:

Mods needed for ISRU?

Without giving any spoilers away, what are the minimum additional add-ons needed to make ISRU work for producing fuels? Is it just Community Resource Pack, or will other items be needed?

I'm only interested in producing fuels in-situ, like stock, but within Rational Resources and JNSQ constraints.

You don't actually need any mods for ISRU, there are stock parts that will mine and refine Ore and turn this into Fuel. However if it is anything other than liquid fuel, oxidizer or monopropellant (for modded engines, life support, etc) then you will need mods and/or patches to do this.

EDIT: Of course if you're looking for things to make this easier in JNSQ, I'd recommend ScanSAT to scan for the resources 

Edited June 28, 2019 by Pleb
Learnt how to read

[Gordon Fecyk]

46 minutes ago, Pleb said:

You don't actually need any mods for ISRU,

Not on stock worlds normally. But my understanding is that JNSQ requires Rational Resources and one of either CRP or something else to enable mineable resources to begin with. Just cheating a stock resource scanner into orbits or various worlds, and yes making sure said scanner is in the correct orbit, a stock scan yields no surface resources at all.

I'm not looking for 'easier,' though ScanSAT is a wonderful add-on for proper surface scanning. I could remove RR and revert to the stock ore configs, but I don't want that. I also want to keep add-ons down to a minimum.

[jdub3350]

Is 1.7.0 or 1.7.1 available for download somewhere?  I can only download 1.7.2 it seems from the store, and I'd like to use .0 or .1 since Kopernicus is available for those versions, as well as alot of other mods that aren't up to 1.7.2 yet. 

[ForgiLaGeord]

2 hours ago, jdub3350 said:

Is 1.7.0 or 1.7.1 available for download somewhere?  I can only download 1.7.2 it seems from the store, and I'd like to use .0 or .1 since Kopernicus is available for those versions, as well as alot of other mods that aren't up to 1.7.2 yet. 

On Steam, you can right click the game, click properties, go to the betas tab, and select older versions of the game. Not sure what you can do if you've got the KSP store version.