Sigma88

the colors exported by cartographer are those used by ksp, if you enable the cheat "biomes visible on map" they show up in map view. however the colors are always the same, so it should be easy enough to replace them with an image processor in case you want different colors

if someone is still interested GN has been updated to ksp 1.7.3

it should be pretty easy to set up a cfg to make SD rescale this mod, something like Galileo's Rescale mod https://github.com/Galileo88/Rescale

just in case you want to try this in ksp, I have a PQS mod for those types of planets https://github.com/Sigma88/PQSGroundCube/tree/master/[Source]/Distribution not sure it still works

I love kerbal-maps so I hope this is successful if you need any help with cartographer or anything else feel free to ping me

yes that's what I understand as well, as long as the two stars are added as an extra system this is possible with SB, if they are supposed to replace the stock sun as the new center of the ksp universe, I am not 100% sure it would be possible to do with SB

it should work fine with SB, this is how you should set up the system 1- put the primary star in the final orbit for your system (the orbit that the barycenter eventually will have) 2- put the secondary star in orbit around the primary star, the semiMajorAxis of the secondary star should be the final distance you want between the two stars 3- add the "SigmaBinary{}" node to the secondary star (make sure to add the parameter name = xxxxxxx because otherwise SB won't work) 4- test that the system works 5- add Barry in orbit around the primary star, you need to find an orbit that will keep the planet always in the correct place (if you have issues with this step ping me on discord I should be able to help) 6- check that Barry is in the correct Sphere Of Influence, if not you might need to put barry in orbit around the secondary star

you are right, for some reason I have it in the changelog but I never released it... weird here's a link to an "unofficial" release, I have no way of knowing if it will work, if this won't work you might try v0.10.1 or v0.10.3 but I can't assure you they will work either

SD 0.10.4 is for KSP/Kopernicus 1.7.1 for 1.6.1 try SD v0.10.2 that version was for KSP 1.6.0 however the next version of SD is for KSP 1.7.1 so either 0.10.2 works or I never released anything for 1.6.1

SD is not on ckan, you should install the mod manually and choose the correct version for that ksp version, I don't remember which one it was, maybe looking at the changelog you can see when I updated to 1.6.1 Maybe @HebaruSan can be of help

you got me worried for a moment there I checked and SD only scales the buildings once per KSP run. so it could be possible that KK saves the increased size every time you run ksp and so you get bigger and bigger buildings between game sessions. However when I made SD I made sure my modifications were applied after KK did everything so that you don't get any SD change saved unless you edit the buildings using KK while the planet is rescaled (which you are not supposed to do anyway) however, getting a different size at every scene change should not be caused by SD

Changing only rescale and resize should be fine however you might want to change a couple of more values as well If you are not sure about the math you could check out "Rescale!" a mod by galileo that provides some setups for SD Not sure it has 2.5 tho If you want to run SD you need KSP1.7.1 and the latest kopernicus If you have those but you still have problems you can follow the link in my sig for a list of file that I need to take a look at your issue

thanks, I'll take a look to see if there is anything I can do to avoid that

well, this looks great so congrats on the work. if you happen to have some screenshots of the ugly results could you send them to me, it might be a bug that I need to fix

I would like to know if there is a particular reason for this decision not that I am complaing or anything, but if there is a particular issue that turned you off the mod I would like to know it so that I might see if it is fixable

I think you mean 1.7.1 because kopernicus hasn't been updated to 1.7.2 yet

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

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

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

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. 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: or of course use a patch like this:

I know, I just wanted to make it explicit for those people who might be confusing TweakChutes the mod with the compatibility cfg that is part of JNSQ

Technically TweakChutes comes with just the plugin, what makes the change is the cfg that is part of JNSQ But it is correct that the cfg does not affect the ModuleParachute, it only makes a copy at :FINAL (even though I have already made a better cfg for the guys to include in the next update) seeing as JNSQ uses FINAL, FAR renames the node before JNSQ (see here and here) so the JNSQ patch will simply not apply which means TweakChutes is disabled in JNSQ if you install FAR

this would be my suggestion: :LAST doesn't seem to work as far as I can tell nevermind I didn't have a :FOR[JNSQ] so that's why my :LAST[JNSQ] was failing. I didn't know that was a requirement

ok, apparently now MM spams the logs with every patch that is applied. this will probably favor using the :HAS[] rather than not using it. I wasn't aware MM did that now, it doesn't seem to be a good idea, but I'm sure they have their reasons for doing that

I never liked to use :FINAL but in some limited cases I think it's fine. using it with tweakchutes should be fine. last time I checked MM it was some time ago and LAST[JNSQ] wasn't implemented, if it is now .. this is a wonderful news and the cfg can be changed to that, even though it's not as crucial for this specific mod as it would be with others. finally, I don't see the difference between using @PART or @PART:HAS[whatever] it won't give you any advantage to use one over the other as far as I can tell so my suggestion would be to use whatever will make people stop complaining for nothing