Galileo

[1.7.x] JNSQ [0.7] [17 June 2019]

Recommended Posts

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.

 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
Posted (edited)
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 by Jognt

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Posted (edited)
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 by Jognt

Share this post


Link to post
Share on other sites

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 :D

 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Posted (edited)
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 by OhioBob

Share this post


Link to post
Share on other sites
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.

 

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites
Posted (edited)
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 by OhioBob

Share this post


Link to post
Share on other sites
8 hours ago, Galland1998 said:

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

Thanks Galland.

Share this post


Link to post
Share on other sites
Posted (edited)

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 by Jognt

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
Posted (edited)
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 :wink:

Edited by Pleb
Learnt how to read

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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. 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.