Miracle Magician

Well, recompiling directly with 1.7.2 seems to work for me Can you try this? https://github.com/Real-Gecko/KSP-SimpleLogistics/files/3317417/SimpleLogistics.zip

Oof, I meant no offence, just meantioned that video because according to him node is related to drag, and it seems to work that way... Maybe his theory is entirely wrong and messing with parts' location is what his drag exploit really was. And I'll make sure I read the comments before mentioning something false... Sorry for that

By the way I think stock drag system still uses node for calculation... Stratzenblitz's most recent video exploits this

Hmmm... Maybe I'm using an outdated version of KJRn Edit: OK, I have big stupid... I added ModuleDockRotate to KJRn's exclude file, not knowing it is just meant to fix incompatibility with KJRc

I think, whether this mod will gain further compability with KJRnext because of the new robotic part state API in 1.7.2?(https://forum.kerbalspaceprogram.com/index.php?/topic/184025-wip-kerbal-joint-reinforcement-next/ seems to be mentioned in the "Info For Developers" section) As far as I've seen currently this mod just excludes all the docking ports from KJRn (Welp... Actually I can't confirm this), making crafts more wobbly.

https://github.com/Galileo88/JNSQ/issues/6 Well, I have a bad news... A small one though

Unfortunately you need to wait until July 3rd, since this mod only updates every new moon.

Currently no, but I've already opened a pull request on github. It's literally changing two letters and it will be compatible.

@Sigma88It's just a lame joke made by me... I know about the open source rule

@4x4cheesecakeI smashed the dll into a decompiler and it simply says this, maybe some code can't be decompiled: protected override void FixedUpdate() { if (deploymentState == deploymentStates.SEMIDEPLOYED) { base.FixedUpdate(); return; } float deployAltitude = base.deployAltitude; base.deployAltitude = 0f; base.FixedUpdate(); base.deployAltitude = deployAltitude; } Pls don't kill me for lurking into your file @Sigma88

AAAAAAA! I opened my minmus L4 save with a retrograde minmus config... Bob becomes a bunch of spaghetti and went through the ground.

Ladies and gentlemen! I did it! I landed on L4 minmus with ion thrusters and 4X rescale! I used 5531m/s of DeltaV (that will be 2765.5m/s for original size, and it'll be persumably lower if used a conventional vessel). Just to flex on all of you Just to prove it is easy enough to get there, I only loaded my game once because stupid me forgot to set my thrust back to 100% when doing minmus circulization. The thing is, don't set the orbit inclination of minmus too high. I set it at 3 degree, and it already wasted almost 1000m/s of deltaV for me, I entered minmus with a near polar orbit. Maybe 0.5 degree would be enough. screenshots: So what I mean is, yes, it's not hard to go to minmus with Principia because of its awesome planning features. However, 2 years of travel time (I got an encounter with minmus 2 orbits after launching) will make minmus significantly harder with life support mods.

Hmmm, is putting minmus at original place/inside the orbit of mun, but put it at L4 when principia is installed an option? Because I think provide a little unique experience for principia players gonna be fun... That is, based on the assumption that getting there with principia is easier than stock. I'll test it out a few hours later when I get my hands on my laptop.

Is it done with Principia or stock physics? I believe with Principia this will somehow become a lot easier, since vessels will have a natural tendency to stay at L4, and minmus will slowly pull the vessel towards it. Rotating reference frame comes from principia would also come in handy.

If it's at L4, I think time could be sacrificed to get a lower delta v? By barely escaping kerbin's SOI, put the vessel in an orbit that has a slightly shorter orbital period than one year, And the vessel will slowly drift to L4. You know, not everything can be done by a simple Hohmann transfer. I didn't test that and can't confirm whether it will work though... Don't mind that @, I can't delete that on my phone for some reason

BTW, this is TWP's readout for Cruithne orbit version of minmus (DeltaV should divide by 2 since I'm playing 4X resized version) That's almost 6Km/s of ejection dV!!! Don't know whether it is accurate though since it's in such a special orbit...

Compatibility of planet packs is basically dependent on Kopernicus, which has a version lock and haven't get updated to 1.7.1. So, sorry, not compatible!

I'm using fatou with 1.7.0 right now. But since Principia only publishes a new version every new moon this version only has source code released, not the binary, so I compiled it myself. Version fary has some glitches and is not compatible with 1.7.0 so I did that. If you want, I can send a copy of my binary to you because the compile time of Principia is so long, and during that time CPU usage will reach 100% and the computer will almost freeze.

Actually, I didn't do any test. I'm not good at computer at all! What I did is only installed principia, opened tracking station, used bettertimewarp to warp some 100 years and see whether all the planets are at the place where it should be. Maybe you can ask for help from Principia's developers about how to do an actual test. After all Principia was originally an orbit stability testing tool!

I remember someone mentioned somewhere that retrograde/resonance orbit helps with stablizing planets. Actually I don't want to move mun either, because JNSQ is a 2.7X planet pack, which is meant to bring realistic difficulties to KSP, and Mun's distance to kerbin is proportional to real-life Earth to moon distance. Did I guess that right? Unfortunately I don't have my laptop in my hand right now. I'll try tweaking minmus's orbit a few hours later, lemme see whether I can get a non-weird looking stable orbit!

@Kopernicus:FINAL { @Body[Minmus] { @Orbit { @semiMajorAxis *= 0.75 } } @Body[Mun] { @Orbit { @semiMajorAxis *= 0.5 } } } Well, I did this and the kerbin system is stable again. The cause of minmus drifting away is simply it is too far away from kerbin, because now mun is at the place where minmus was at before.

My guess is that it will be compatible, but since this is a 2.7X resized planet pack, so those planets from other planet packs will look disproportionly small; and if tho star is too close to Kerbol, maybe two systems will overlap with eath other. And I ran this planet pack with principia just now. Guess what planet become unstable? It's Jool's moons again? It's newly added planets? No, it's Minmus. Seems Minmus is too far away from Kerbin, it just casually drifts away and starts to wander around Kerbol. Suprisingly except minmus, all the other planets are stable.

Oh no I accidently clicked 4 star instead of 5... WHAT HAVE I DONE I WANT TO KICK MYSELF IN THE FACE

IKR, my English is just not good and I think I didn't express what I meant precisely. I was just mentioning it doesn't work because nobody mentioned whether this works or not

Sorry, it seems not working for me, I still get the weird blue tint when switching to ScaledVersion I'm playing 10X rescale with some code from RSS's watchdog.cs so the effect should be same as RSS