Jognt

@severedsolo Thank you, thank you so much for this mod. In all the time I've played KSP I did not know this existed. I hope you and your daughter are doing well. Having a brother with autism (and being on the spectrum myself) I know it can be ... difficult. I wish you the best

Pics or it didn't happen...

Anything that goes on a bouncing frenzy usually settles down just by setting it to custom without even modifying any values. It'll probably find a reason to resume bouncing later on though (especially with planes, where the mass of the craft changes as fuel is spent) so it's probably that sweet Squad magic going on. @Tincan70 Custom spring/damper is also a decent method to gauge whether you need 'moar' legs/wheels. Max spring should net you quite a visible difference to min spring if the current amount of legs/wheels can carry the load. To be able to set these values, be sure to enable "Advanced Tweakables" in the game menu. ps. I cannot tell you how much time I've spent trying to figure out a way to get the legs/wheels to behave properly. It's truly something that vexes me.

Everyone is. I usually 'fix' it by either adding/removing wheels/legs, or setting a custom strength for the spring/damper. Edit: The reason you're not seeing bug reports all over the place is probably because people expect KSP legs/wheels to behave strangely. I wouldn't be surprised if people were to flood the forum asking "Which of my mods fixed the legs/wheels?" if squad were to somehow create functioning versions. (Or even "Help, my legs/wheels work as they should, now my KrakenKraft no longer works! How do I make them work as usual again?")

Re: "Is that normal?" -> It may well be, I don't know for sure. I do know that that folder has files with empty nodes in it so I can imagine that being normal. I'll admit troubleshooting visual mods is mostly out of my league, but I'll try and help where I can: Could you post a screenshot of your GameData folder and upload a copy of your Output.log file?

At the very least it means you're not running DirectX. I have no experience with Linux though so I can't help you with that sorry

Are you running dx9 or something custom?

I don’t think that’s his game data folder. @Angleton I wouldn’t copy over those old scatterer/eve/etc folders, sounds like you followed the instructions. The lack of contrast with planets is due to Scatterer. That’s going to be up to you to decide whether you want it or not. I don't know where those lines on Minmus come from, they look wireframe-y though. You could try removing the KSPRC folder entirely to check whether all works as intended. Then before you place it back, make sure it's in the right place -> GameData\KSPRC with indeed just Textures and PluginData folders left in there.

The stock flt-400 has a texture that looks a lot like the Mk1 fuselage, the ‘lack’ of such a tank is only obvious if you run ReStock (which lacks such a texture) or if you’ve got a very keen eye for detail You shouldn’t be seeing any ‘locked part’ messages anymore if you’re using that MM CFG above though.

The three tech trees I've read the most about are Probes Before Crew, Unkerballed Start, and Simplex. I'm running Probes Before Crew (and boy does that add difficulty when you need control to send up your satellites that are there to give.. control) I wouldn't worry too much about contracts/tech tree integration/etc. Kerbin is still Kerbin, Mun is still Mun. If a parts mod has contracts, they'll work regardless of whether you're on JNSQ or stock kerbin.1 1 Terms and Conditions may apply.

There's config for Strategia in JNSQ that makes some minor (and appreciated) tweaks to the regular Strategia choices, but in general it's still Strategia as you know it. Contract wise: the usual suspects are available to choose from. Now Tech Tree wise.... Take this one bit of advice from me: Only go for an unmanned-first tech tree if you really don't mind (or really like!) rough starts. Eh? What's that Jeb? No you can't go out to play yet, I spent a fortune getting that command pod so you'll be using it to complete our commnet constellation until you die from it! What's that? No, I don't know where Valentina is. No, that's totally not a crashed pod in the ocean. You've been on the ground too long, it's getting to you Jeb.

If you want to know whether your changes went through: Open up your modulemanager.configcache and do a search for "parentUrl = Kopernicus/Config/System" without the quotes of course. JNSQ adds its own nodes and removes the old ones during the FOR[JNSQ] pass so any changes done before that point will most likely not go through. For all the timings after that it should have worked fine though. Like Ohiobob mentioned Edit:

Yes it does. I've also posted fixes for the cargo bays (especially the drone-like one as it didn't work, at all) on this page. Mods like this that primarily add an x amount of parts will usually work just fine regardless of KSP version. It's the mods that hook into code and stuff that need to be checked when KSP updates

Judging by the number of rover-backflips I would say: No.

Happens with stock too. I just tried it while testing something else. Try adding moar wheels. Edit: never mind, you meant landing legs, not gear.

With "Require signal for control" enabled you can't even extend the antenna without a signal. Jeb's been on more antenna-extending-EVAs than he can count!

The blue line isn't inaccurate. They both show a different thing: The blue line show you the trajectory you will follow and where you will land relative to the current point in time ; The red cross shows you where you will land. Meaning, by the time you've reached the end of the blue line, the planet will have rotated and you'll be on the red cross. Try doing a deorbit burn from low kerbin orbit and set the red cross on KSC. The blue line will 'hit the water', but because the planet rotates while you're reentering, you'll land on KSC. Edit: Note that vessels going through the atmosphere will only experience drag if they're actually within physics range. You can have a ship in the upper atmosphere that never reaches orbit, but as long as you don't actually load to it it will keep going in circles. The exception is a certain pressure height that corresponds to 20km for Kerbin. Anything going below 20km without being loaded will be destroyed regardless.

I think that's 'by design'. SFS hides several parts and applies their texture to an equivalent part. I have a personal patch that makes it available again (because the Mk1 skin isn't on the FLT-400), if you want that too (and have ModuleManager installed), place the following in a text editor, save it to your gamedate folder with a .cfg extension. @PART[MK1Fuselage]:BEFORE[SimpleFuelSwitch] { oldcategory = #$category$ oldTechRequired = #$TechRequired$ } @PART[MK1Fuselage]:AFTER[SimpleFuelSwitch] { !TechHidden = dummy @category = #$oldcategory$ @TechRequired = #$oldTechRequired$ !oldcategory = dummy !oldTechRequired = dummy } Complexity is due to running modded techtrees and I didn't feel like checking where the part's supposed to go in them, so now it's automatic. =================================== Personal question: Is it possible to have the fuel displayed in tonnes for other tanks LF/O tanks? There's quite a few tanks from mods in my parts list and it trips me up that they don't have the tonnage shown. I thought about just 'broadening' the cfg that applies the SFS module to parts, but I don't know if the .dll would freak out if I did that to tanks that I don't need the switching for, just the tonnage shown.

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.

I think you've summarized it better than I ever could. Thank you. 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.

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.

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.

Thats precisely why I left it empty. You wouldnt include an empty FOR, and theres no modB to trigger. Of course its setup FOR my own tweaks folder locally. The reason a FOR[myself/something] is important is because of the order of patching. Patches without a directive are executed before the BEFORE/FOR/AFTER passes. This means currently patches are done before almost everyone else adds/removes stuff. Which can cause problems and incompatibilities. ================== Other than that: Any ideas on the duplicated "Perform all science" PAW entries? Edit: I know why it's only 'sometimes' that I get the double entry. The new futuristic suit is its own part, whereas the vintage and regular suits are a mashup of the Stock KerbalEVA and the Serenity KerbalEVA that adds the ROCScience to them. All Y'all adds its modules to all three of them, but in the case of the vintage/stock suits they get both their 'own' module and the module from the Serenity ROCScience KerbalEVA added to them. The Futuristic suit is its own part so that isn't affected.

I seem to have found either a bug or some sort of conflict.. Command Pods seem to be unaffected by that feature that makes them not listen to SAS/input as they still stop moving just fine if I enable stability mode. Before I give you a log filled with a several hours long session; Any specific actions you would like me to take?

Because I removed the name of myMod and it looked naked when I removed the whole FOR. Edit: And it's a slight hint that All Y'all doesn't really use FOR which means that mods adding experiments in their own FOR pass won't be 'supported' by All Y'all because All Y'all is done adding modules by the time those get added. Though in that case an AFTER or a LAST would be better Edit 2: The Multiple entries on kerbals thing may be due to every suit type being a different 'part'? Edit 3: ModuleManager.configcache has 2 parts named KerbalEVA (one for stock, one for BreakingGround). The second one adds the ROCScience to the regular Kerbal, but both 'parts' have All Y'all's science module. Could be due to how Squad merges parts (apparently?) that causes the two All Y'all modules to be merged in? Could work around that by excluding parts that don't have any of the regular partAttributes set?