CoriW

I didn't even know I needed this, until... Here it is! Thanks.

Hey so just a heads up I've now updated the JNSQ PBC Rebalance to use Module Manager patches instead of full replacement configs. It's much cleaner now and more compatible than ever. (Just thought I'd mention it, I'm assuming based on @JadeOfMaar's post in my thread that you guys were waiting for me to change that to put it up in the OP.)

OFFICIAL RELEASE 0.2.1 Hey everybody, so after finally getting some testing done and verifying that all of the new Module Manager patches work properly I've decided that I'm happy enough with it to go ahead with an official release. Functionally not a lot has changed from the 0.1.0 release, the largest change was the migration from full replacement config files to Module Manager patches which is much cleaner and much more compatible with other mods. Aside from that I've fixed a couple of typo's from stock PBC, fixed a nasty reference error from the unofficial 0.2.0 release, and added version checking. The only notable change to any contracts is that I've increased the altitude requirement for the "Skim the Corona of Kerbol" contract, as it was still at stock values which made it impossible to complete. I've set it to a number that should still provide a good enough challenge, but still be achievable. Though I will mention the actual number I chose was suggested by @DR_RDR. ALSO IT IS VERY IMPORTANT THAT IF YOU ARE UPDATING FROM AN EARLIER VERSION THAT YOU MUST COMPLETELY DELETE AND REINSTALL PROBES BEFORE CREW, THE NEW VERSION NOW REQUIRES THAT ALL ORIGINAL PROBES BEFORE CREW FILES BE PRESENT. IT IS NO LONGER REQUIRED TO DELETE OR OVERWRITE ANY PROBES BEFORE CREW FILES. VERSION 0.2.1 - Added KSP AVC version checking - Fixed Skim the Corona of Kerbol altitude being too low, increased it from 180,000,000m to 540,000,000m to account for the increased scale of JNSQ. - Fixed mod reference in ScienceParamMod patch which caused Module Manager to encounter a fatal error if you did not have Celestial Body Science Editor installed. (This error was introduced in version 0.2.0) VERSION 0.2.0 - Migrated from the use of replacement .cfg files for PBC stock bodies to Module Manager patches - Fixed Typo in Parameter of Stock PBC, Under Crewed Kerbol Contract, Parameter "landPK" changed to "landCK" - Fixed Typo in Parameter of Stock PBC, Under Probe Tylo Contract, Parameter "landPV" changed to "landPT" @JadeOfMaar Thanks for the tips you gave me regarding the MM Patches, without you I'm not sure if the migration to Module Manager patches would have happened at all. I'm happy it did, as it's much cleaner for me, the players and other modders.

Okay sounds good, let me know if you figure anything out. Also one other question.. I noticed that in JNSQ the flying low altitude is 500,000,000m .. What would be your opinion on that altitude for the contract? Or would that just simply be too difficult to complete?

Hey thanks for the input, every little bit helps out a lot. Regarding the Kerbol probe mission, I was actually looking at that while working on 0.2.0 but ran out of time and it didn't get changed. But I can say this will be done in the next update. (Since I've released 0.2.0 unofficially I may skip an official 0.2.0 to avoid confusion and just push the official release as 0.2.1) As for making probe returns optional, that is actually a wonderful idea (in my opinion) and would also make so much sense. (Why return a probe if you dont have to?) I'll look into that next time I'm working on the mod. EDIT: One question, if you make the return portion of a contract optional, what keeps the contract from auto-completing when you have everything except for the final optional parameter completed? Or on the contrary if it doesnt just auto-complete then how do you complete it without doing the final optional parameter? (I'm still learning how contracts and contract configurator work, so bare with me) I'll note I'm not actually at my computer right now, on the road coming back from a trip. Probably won't have a chance to work on the mod until tomorrow evening, so the above questions may answer themselves when I actually sit down to work on it.

In most cases many mods will work on later versions of the game than the version which they were compiled against. Only certain updates (I believe KSP 1.3 was one of then) will break a lot of mods. It all depends on what a KSP update does under the hood on if it will break mod compatibility or not. That isnt to say that every mod will work on every update either, but many will retain most if not all functionality on most updates.

Hey everyone just a heads up I was planning an official release tonight after some testing but an emergency happened IRL and I wasnt able to get any testing done. I'm going away on a trip this weekend and won't be able to do any testing so I'm going to push an unofficial release for now and hopefully it all works. The MM patches are untested so I hope they all work. Sorry for the delays. https://www.dropbox.com/s/nkt0jay3cb0o8gp/JNSQ_PBC_Rebalance_0-2-0.zip?dl=1 EDIT: Note that for version 0.2.0 you DO NOT NEED TO DELETE OR REPLACE any PBC files, on the contrary you now REQUIRE ALL OF THE ORIGINAL PBC FILES BE INSTALLED for the patches to be applied properly. Hopefully next week I have some more time to push an official release. Edit2: Also I will note, minus one or two minor little bug fixes, 0.2.0 is effectively functionally identical to 0.1.0. The primary change was switching from full replacement config files to MM patches for all stock PBC bodies.

Okay so just a heads up, this evening I had just enough time to get everything ported over to Module Manager patches, however I did not have enough time to do any testing to make sure that everything worked okay. So while I was tempted to release the new configs without testing I opted to wait until I have more time, which likely will not be until Wednesday evening. That all being said @JadeOfMaar I was wondering if you would be willing to look over the new configs and let me know if the MM syntax and everything looks alright? It would be greatly appreciated. If interested let me know and I'll PM you the links to the new configs on my DropBox.

Hey so the reason I hadn't used Module Manager was that I wasn't sure if it could be used to modify Contract Configurator configs. But if that is the case that I can use it for that purpose I wouldn't hesitate to do it that way as I also prefer the use of Module Manager to modify things. Consider that part of why this was released in addon development. Also @JadeOfMaar I am aware of the intended use of :FINAL and would not use it here, thanks for the heads up though. I should have some time tonight to go through and modify the patches into MM configs. @garwel Download link should work now, first time using SpaceDock and forgot to hit the publish button.

Should be fixed, forgot to hit the publish button. This is my first time using SpaceDock lol

Hello, so recently over the past week or so I've been working on a modification of some of the Probes Before Crew configs in order to rebalance it for and make it compatible with JNSQ. My rebalance is currently in the testing phase, but I have created a forum thread in the addon development section in order to hopefully get some volunteers to help me test the balance. @JadeOfMaar @Galileo I was wondering what the potential would be for mentioning the rebalance under the recommended mods in the OP (or somewhere else people can see it) for those who desire a contract pack for JNSQ? In theory the contract pack should work just fine without the other aspects of Probes Before Crew installed if people don't want that whole package, since it's made exclusively out of .cfg files it should be quite modular.

Hello again! As outlined in my previous post I've been working on a rebalance for this mod which includes compatibility with the JNSQ planet mod. I have now released a development version of the rebalanced configs for testing here. @_Zee Not sure if you'd be interested in linking this anywhere, perhaps might be better to link in the JNSQ thread. I'll mention it there as well.

JNSQ Probes Before Crew Rebalance / Contract Pack By CoriW DISCLAIMER: Some config files packaged within this mod are modifications of config files used in the Probes Before Crew mod and as such I've chosen to license the entire mod under the original MIT license of those config files. This mod is intended to serve two purposes, the first is to provide compatibility between the JNSQ and Probes Before Crew (PBC) mods, as well as provide a rebalance to the planetary science modifiers and contract rewards / penalties of the PBC contract pack to better work with the increased scale of JNSQ. The reason that I have decided to create a dedicated thread for these configs is because I would like to have as many potential testers as possible to ensure that these configs are correctly balanced against the native 2.7x scale of the JNSQ mod, and the last thing I would want to do is clutter up the JNSQ and PBC threads with pages of off topic discussion relating to a rebalance. What This Rebalance Does VERSION 0.2.1 CONTRACT PACK (Rescale Fixes) - The initial Kerbin contract parameters have been altered to account for Kerbin's increased atmosphere height for the upper atmosphere and reaching space contracts. - The Dive into Jool's Atmosphere contract parameters have been altered to account for Jool's increased atmosphere height. - The Skim the Corona of Kerbol contract parameters have been altered to account for Kerbol's increased atmosphere height. (Science, Reputation, and Fund Rewards) - Some of the closer celestial bodies to Kerbin may seem as if they've had a slight reduction in rewards compared to stock PBC, which is more noticable when it comes to Eve and Duna, this was done due to the increased number of celestial bodies in JNSQ. This is also balanced out by the father out planets having increased rewards compared to stock PBC. For example, JNSQ Eeloo has moderately higher rewards than stock PBC Eeloo rewards and Nara has considerably higher rewards than stock PBC Eeloo rewards. (Failure Fund Penalties) - Most of the fund penalties for failing a contract from stock PBC have been reduced, this was done primarily in order to prevent the fund penalty for outer planets past Eeloo from becoming too excessively high. The resulting high end of the range is increased from 450000 to 504000 funds. (Kerbol) - Fund rewards for skimming the Sun's corona have been increased, due to the increased size of the system and with it the significant increase in DeltaV this now requires, it seemed warranted. (Inner Planets) - Due to the lesser number of inner planets and the increased hostility of the inner planets such as Eve's extreme atmosphere and Moho's extreme heat, a slight bias has been applied to the rewards for the inner planets increasing their reward values compared to outer planets. For example the rewards for going to Eve will be slightly higher than rewards for going to Duna and the rewards for going to Moho will be slightly higher than rewards for going to Edna. (JNSQ Bodies) - All JNSQ Bodies have had contract configs added and balanced against the stock bodies. SCIENCE PARAM MODIFIERS - Due to the increased number of bodies in JNSQ, most of the science paramaters have been reduced from stock PBC. The only increase is Kerbin which has had it's parameters increased from 0.8 to 1.0 due to the increased size of Kerbin. The parameters of Kerbin's moons however remain untouched. - Gilly's parameters have been reduced from stock PBC to match those of it's parent, Eve. - Jool has had it's flying low parameter increased due to the inherent difficulty of flying deep into a gas giant's atmosphere. - Due to the addition of a second gas giant with it's own assortment of moons, all parameters of Jool's moons have been reduced by 0.5 from stock PBC. - Laythe, which in stock PBC had all parameters 0.5 higher than the rest of Jools moons has had it's flying high, space low and space high parameters reduced to match the other moons of Jool, while the landed, splashed, and flying low parameters have been set 0.5 above the other moons of Jool. - Due to Eeloo acquiring two new moons with JNSQ, it's parameters have been decreased by 0.5 from stock PBC. - All JNSQ Bodies have been added and have had their parameters balanced against the stock bodies. You may find a spreadsheet containing both the original and rebalanced PBC Contract Pack rewards and penalties HERE, you may switch between the original and rebalance tabs at the bottom of the spreadsheet. How To Download and Install 1. Download and Install the JNSQ mod HERE. 2. Download and Install the Celestial Body Science Editor from DMagic's Modlets HERE. (This used to be bundled within the Probes Before Crew download, but has been removed as of the version 2.7.) 3. Download and Install the Probes Before Crew mod and all of it's dependencies HERE. 4. Download the JNSQ Probes Before Crew Rebalance HERE. 5. Extract and Merge the GameData folder from the ZIP file into your Kerbal Space Program directory. IF YOU ARE UPDATING FROM 0.1.0 TO A LATER VERSION YOU MUST COMPLETELY DELETE AND REINSTALL PROBES BEFORE CREW, THE NEW VERSION NOW REQUIRES THAT ALL ORIGINAL PROBES BEFORE CREW FILES BE PRESENT. IT IS NO LONGER REQUIRED TO DELETE OR OVERWRITE ANY PROBES BEFORE CREW FILES. If you have any feedback regarding the balance of the contract rewards or have any suggestions for possible additions or modifications, please feel free to post in this thread. All feedback is greatly appreciated! To-Do - Look into making probe return contract parameters optional. Changelog VERSION 0.2.1 - Added KSP AVC version checking - Fixed Skim the Corona of Kerbol altitude being too low, increased it from 180,000,000m to 540,000,000m to account for the increased scale of JNSQ. - Fixed mod reference in ScienceParamMod patch which caused Module Manager to encounter a fatal error if you did not have Celestial Body Science Editor installed. (This error was introduced in version 0.2.0) VERSION 0.2.0 - Migrated from the use of replacement .cfg files for PBC stock bodies to Module Manager patches - Fixed Typo in Parameter of Stock PBC, Under Crewed Kerbol Contract, Parameter "landPK" changed to "landCK" - Fixed Typo in Parameter of Stock PBC, Under Probe Tylo Contract, Parameter "landPV" changed to "landPT" VERSION 0.1.0 - Initial Release

@_Zee Hello, I'm currently playing with JNSQ and have decided to write up some configs to integrate the new JNSQ bodies into the contract pack and science param modifiers. Looking over the contract pack I created a spreadsheet showing every reward for every scenario outlined in the contract configs so that I could visualize any patterns of how you chose the values and I now just need to figure out appropriate values for the JNSQ bodies. My question is what method did you use for coming up with the original reward values and failure penalties? I'd like to perhaps use a similar method in order to provide some consistency to your existing values. Some of the numbers seem slightly odd like Dres which is the only body to have values not rounded to the nearest 1000 (for example Dres failures funds (crewed) is 250507) Also I've noticed that most of Jools moons (except for Laythe) have random variables applied to them, while no other bodies have this. Here's the spreadsheet I mentioned, ignore the JNSQ tab as it's not final. I started filling out sort of randomly chosen values for the new bodies and then stopped half way through to ask in this thread. https://docs.google.com/spreadsheets/d/1YURPYLSa7qPejoFQG0xR3CjsnX75nf0L2GhxVrMOXsI/edit?usp=sharing EDIT: Actually I suppose since JNSQ is 2.7x scale, that the original values may actually be too low for the upscaled bodies and may make it too difficult to progress as it will take more fuel and larger rockets to get places.. I'm still interested in your response to the above but I may have to consider a complete rebalance just aimed at JNSQ specifically. Then again I also play with Monthly Budget so funds don't really affect me in the way they do a typical player so I'll have to do some testing perhaps on a "stock" JNSQ install. EDIT: Okay so.. I've ended up just deciding to do an entire rebalance .. If you can call it that. Basically I just wrote some formulas that look at how far away a celestial body is, in which direction it is (inward or outward) in the system, as well as whether it's a moon or not and then it does some math and spits out a bunch of values for rep rewards / penalties, fund rewards / penalties, and science reward / penalties. So yeah not sure if you'd call that a rebalance since no actual testing has been done on if the rewards and stuff seem "balanced" or not, that'll take some testing. (I will note though for layers 1 and 2 of the missions I've left those hand written, it's just layers 3 and 4 that the above applies to.) I've also only done this on the spreadsheet mentioned above under the JNSQ tab. I've yet to have the time to actually convert all those values into actual config files. I'll probably do that next time I have an evening to spare (no guarantees on when exactly that will be, hopefully sooner than later. Once I've done that however I may throw together a post in the addon development forum so that I could perhaps find some volunteers willing to assist with testing the balance, since the current version was created via math I'm sure there will be some tweaking necessary. After some (hopefully) extensive testing I may contact the JNSQ guys and see if they'd be interested in having it come with JNSQ as an (optional?) patch at some point in the future. It's funny though I've been back at KSP for over 3 months after a very long hiatus and have yet to actually play a proper game ... Just modding modding modding. And when I did try to actually play a game I got the kOS mod and then spent an entire month programming lol! I swear I tend to do this with any game I play.. Mod it more than I play it.

Hey just a quick question, does changing the sunlight intensity affect solar panel output? Asking for both stock and Kopernicus solar panels.

@Thomas P. Adding onto this, I've done some testing and it appears that even without Resonant Orbit Calculator, if useOnDemand and useManualMemoryManagement are set to false, all of the scaled space textures of all planets change to whatever template planet was used. For example, in the JNSQ planet mod many of the planets used Moho as a template and so when those settings are false, it results in many of the scaled space textures of the planets using Moho's texture while the actual PQS of the planet remains correct. Also a few of the planets such as Eeloo just become a white sphere. This would explain why @linuxgurugamer's mod Resonant Orbit Calculator is not generating the correct images, as the scaled space textures of the planets themselves are incorrect. For example, while using the following MM config in a JNSQ install.. This is what Eeloo's moon Celes looks like... Strikingly like Moho, isn't it? (Can confirm this is not what Celes is supposed to look like, and that the template planet used to create Celes was in fact Moho.) @Kopernicus:FINAL { %useOnDemand = False %useManualMemoryManagement = False } And this is what Eeloo looks like.. As mentioned above, a white sphere. I can confirm that this was not the case before the major refactor that came with Kopernicus 1.7.1-1 as this is what @linuxgurugamer's Resonant Orbit Calculator generated prior to that version of Kopernicus being released. Although one thing I will also note is that even before Kopernicus 1.7.1-1, some planets being white sphere's was still an issue as can be seen in the thumbnails which were created. However some planets were also a bit washed out which may also have something to do with JNSQ being natively 2.7x scale, though that part is merely speculation as I have never been able to track down a direct cause.. I'm no programmer, merely more of a QA guy. (Though I have dabbled in programming in the past, which may or may not help with my QA ability.) Lastly I have collected ALL of the logs from my install and placed them into a convenient zip file. This includes KSP.log, output_log.txt, MMPatch.log, ModuleManager.log, and ALL of the Kopernicus .Body.log files. https://www.dropbox.com/s/2u2znbpff5qxtm8/Kopernicus_Logs_01.zip?dl=1 If you need anything else from me, please feel free to tag me or private message me. As a user of the Resonant Orbit Calculator mod I desperately would like to be able to generate the correct thumbnails again, as I have since lost the correct (yet slightly washed out) ones which I showed in the 3rd screenshot above. EDIT: One other thing which I feel is important to note is that these results and logs were seen in a test install which contained only Kopernicus and it's dependencies as well as JNSQ and it's dependencies.

As far as I'm aware the next version of JNSQ will have city lights included. I recall reading someone thanking the Devs about it a few pages back.

Just out of curiosity, would the end result be the same regardless of which of the two methods you use? (delete and replace vs modify existing) I mean they may have some differences on the dev side but would the end user experience be pretty much identical? (excluding mod compatibility such as the issue mentioned above, I'm speaking from a strictly gameplay experience point of view.)

Okay! So after quite a bit of fiddling around and figuring some stuff out and then contemplating the best planet to start out with, I've decided to start with Tam. I've picked Tam because it was small and quite easy to use as a sort of practice planet and after trying a few different techniques in the editor I was able to find a fairly effective method of mapping out most (hopefully all) of the craters on Tam and assigning them biomes. This shall be my first submission, and most likely not my last. I'd like to propose 3 new biomes for Tam. Biome Map Biome Info, Hex Codes, and RGB Values EDIT: Also I'm not sure how many biomes you guys are interested in having on each planet, as I'm aware my submission will effectively double Tam's number of biomes. The reason I chose to separate the smaller and larger craters and only refer to the smaller ones as potmarks is because I referenced the height map to get all of the crater locations and for many of the smaller ones I was unsure if they are actually craters or simply divets in the ground, which can't easily be determined via the height map alone (though now that I think about it I wonder if the color map may have helped a bit.) That being said if you guys did want to keep Tam's biome count lower you could either merge the potmarks and craters all into a single biome type or remove the potmarks all together (as once again there isn't a guarantee that those are actually craters) but with all that being said, if I was forced to only choose one of the 3 biomes in my submission it would be the twin craters as they are unique to Tam as the only 2 craters on the body that are so physically connected. (There are others that are close or maybe the edges touch, but none that are actually partially interconnected like the twin craters are.) Im not sure when this week I'll have time to take another go at KSP stuff (might not be until Friday) but next time I'm around I'll locally integrate my biome map into Tam and make sure everything looks good. In theory it should all check out based on the height map.

So this may take a bit longer than anticipated.. I've been at it for over an hour now and am finding that the problem isn't creating the biome images.. That's the easy part, the hard part is actually finding areas worthy of their own biomes. I'm going to have to either get really creative, or really generic to come up with much of anything. Starting to wonder how on earth (or Kerbin) I came up with 17 biomes for Arkas. Just looking through my computer I've discovered that I apparently still have all of the Arkas files. All of the biomes actually seem to be fairly generic lol. Lowland Dunes, Midland Dunes, Highland Dunes, Mountains, Crater, Volcano, Volcano Summit, Super Volcano, Super Volcano Summit, Central Dunes, Northern Dunes, Southern Dunes, Polar Lowlands, Polar Dunes, Polar Mountains, Polar Volcano, and Polar Volcano Summit. Most of those is based solely off geographical features, rather than interesting locations in particular. The only deviation from biomes based on geographical features are ones that are based on latitude. I'm noticing that the existing biomes in the JNSQ biome maps are mostly based on a similar premise. Lowlands, Midlands, Highlands, Mountains, Shores, Craters, Deserts etc. It's starting to come back to me just how hard it is to come up with biomes in KSP.. Explains why this thread is needed lol

Ah okay, gotcha. I may have some time tomorrow to take a look and see if I can come up with some interesting biome ideas. And yeah I stepped out all the way back in 1.0.4, I'm sure a lot has probably changed since then. Though I'd imagine a lot of it has changed for the better. (Or at least one would hope that's the case) lol

Hey I'd be interested in helping out. I've dealt with biome maps in the past when I created the Arkas planet mod (which was subsequently adopted by @The White Guardian when I stepped out of modding. Though being as that was almost 4 year ago I may need a slight refresher. Notably when you say horizontally flipped, that means I have to flip it left to right, correct? (I do remember flipping the Arkas biome map back in the day, but don't remember any of the details)

Not at my computer at the moment so this is by memory. They are off by default, go into the tracking station and open the Kerbalism window and there should be toggle at the bottom of that window for the various belt types.

Okay thanks. One other question, if I have FeatureScience off, does the DataRateDampingExponent affect stock science transmission and signal strength, or is it more intended to tie into the FeatureScience data transmission?

Hey I have a question regarding some of the settings in the settings.cfg file in the KerbalismConfig folder. If I set "Science = false" does this completely disable all features of Kerbalisms feature science? And under the comms section of the settings, it says for DataRateDampingExponent that rescaled systems will require a smaller value. By default it is set to 6, and I'm using JNSQ which is a 2.7x scale system, what would be the recommended value for that?