Jognt

What are you attaching them to? The hull or (mirrored) wings? Node-attach or surface-attach? If you attach something with clear front/back/left/right/up/down differences (science parts are quite unique) in the same manner, does this part get properly placed or is it also flipped?

Heya, I was looking through All Y'all's CFG entries and noticed the seperate entries for MODULE[DM*] and MODULE[ModuleScienceExperiment]. I recently updated one of my personal tweakmods to cover all science experiments regardless of module. That way may be of use to All Y'all too: @PART[*]:HAS[@MODULE[*]:HAS[#experimentID[*]]]:FOR[] That should net you all science modules whether they're stock, DMagic-added, UniversalStorage-added, etc. Edit: The reason I was looking through the CFGs was because I was seeing double "Do all Science" entries on my kerbals sometimes. Usually when they were hanging off a pod for a 'flying' EVA report, which for some reason they could not do at that moment.. Adding this due to this being reported before as well. I removed All Y'all for now, but if you have an idea on steps I can follow to narrow down the cause, let me know and I'll install it again. Edit 2: Output.log -> https://www.dropbox.com/s/syi8bx1abv94lbo/qwerty_output_log.zip?dl=0 there's quite a few nullrefs in there though so I don't know how valid even the previous issue was. (kopernicus footprints, which has now been removed, and I think clickthroughblocker which may have just been a one time thing from kopernicus nullrefs?)

Fair enough. I took the liberty to give the SolarPanels.cfg a similar treatment. Just the change in these two .cfg files cut down the amount of patches by 30%. (~6000 to ~4000). Better, faster, safer. What's not to love? Here's what I went with: @PART:HAS[@MODULE[ModuleDeployableSolarPanel]]:BEFORE[Kopernicus] { @MODULE[ModuleDeployableSolarPanel] { useKopernicusSolarPanels = false } } 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? The only issue I had (besides the usual blue VAB icons without TU, the disappearing reentry effects, and the grainy texture filtering problem) was that for some reason the ground textures looked like a totally even color. The ground around KSC was like a green 'area fill' tool was used. This went away when I returned to Dx9.

Like many of us I spend more time in Notepad++ and on the forums than in game. So in my case: I haven’t played enough to know!

Ok, thank you very much!

*dial-up modem sounds* ... how did I never think of this? Thank you very much!

In that case, what value should I put it on? Edit: I'm guessing I should just save whatever values it starts up with to the default profile? If not, let me know

I just had the exact same problem you were having. Turns out I apparently set Director Strength (or something) to 0 in Craft Settings while fiddling with values. Setting it to whatever other number made it work as always. I'd saved over the 'default' config and couldn't find a 'reset' button (which I guess the default cfg was) so now I'm off to reinstall! Hope it's this simple for you too! Moral of the story: Don't let end-users touch important bits

Oh I agree 100% that TweakChute behavior makes sense. (stock behavior doesn't, at all). It's just that there will always be edge cases where an end user uses something in a way it was not intended to do. The scenarios that I can imagine are all in the "k.. whatever floats your boat" range, but they exist nonetheless. I ran your proposed cfg in my install and MM patches applied went from 6075 to just 5119! No noticeable loading time impact that I can tell, but it's a lot cleaner and warms my heart One question though: Why the second filter? Are there moduleParachute's out there without a minAirPressureToOpen key?

If I ever get off my rear to learn to make a proper KSP mod the first mod that I make will be one that adds a vehicleSAS function where SAS only activates if the vehicle is rotated more than 45° off its regular position... Until then, we just have to resort to using DMagic's Orbital Science Magnetometer as a self-righting mechanism. Works very well!

I made a few fixes to some parts, mainly the drone-like cargo 'cockpit' which didn't have a working ModuleCargoBay due to a missing entry, and two other parts where I tweaked the ModuleCargoBay numbers. All three have some cleaning done to remove bits that were unneeded or weren't supposed to be there. Feel free to use it for your own games. @blackheart612 feel free to use it for the shipping cfgs. // Fixes to AirplanePlus ModuleCargoBay Modules. @PART[mk1cargodoorjr]:AFTER[AirplanePlus] { @bulkheadProfiles = size1 // Remove srfAttach profile since it can't be srfAttached. @MODULE[ModuleCargoBay] { @lookupRadius = 0.8 // Reduced radius while still covering the whole part interior. May offer ever so slight performance improvement? (Before: 1.5) !nodeInnerForeID = dummy // Removing entry due to node being undefined and unneeded. !nodeInnerAftID = dummy // Removing entry due to node being undefined and unneeded. } } @PART[mk1dronedoor]:AFTER[AirplanePlus] { @bulkheadProfiles = size1 // Remove srfAttach profile since it can't be srfAttached. @MODULE[ModuleCargoBay] { %lookupCenter = 0,1.875,0 // offset the center of the lookupRadius into the bay itself to be able to cast rays from it. @lookupRadius = 2 // Increased the radius to cover the interior better. (Before: 1.5) !nodeOuterAftID = dummy // Not needed since this part has no open end. !nodeInnerAftID = dummy // Where we're going.. We don't need Nodes. } } @PART[passengeroor]:AFTER[AirplanePlus] // That partName though! { @bulkheadProfiles = size1 // I'm starting to see a pattern here. MODULE // Can't uncomment the existing one, so we'll add a new one. { name = ModuleCargoBay DeployModuleIndex = 0 // Hold the oor! HOLD THE OOR! closedPosition = 1 lookupRadius = 0.8 // *sucks thumb* - About this much? - Confirmed, plenty of Radius. nodeOuterForeID = top nodeOuterAftID = bottom } }

If you want to (still) have some fun with your (fast) rovers: lower the friction control! You can live out your Fast&Furious: Munar Mayhem dreams Be sure to quick save first.

Several settings were moved to the Difficulty Settings menu, I’m going to guess UI size is one of them ;).

Good question. It did it 95% of the time for the first part. Removing it and placing a new first part would trigger it too (so first part, same ‘vessel’). Adding a second part I think didn’t trigger it, but honestly, it’s been a while. Edit: I removed Basic-dV back then and still get nullrefs when I EVA. So that one may not have been related to basic-dV. I’ll check later.

Cheers!

Wow.. that's.. pretty awesome. I'm trying to figure out what some of these settings do. Variables like: - Jitter, Blend_Stationary, Blend_Motion for TAA; - Downsampling, ForceForwardCompat, HighPrecision for AO; - soft_knee, threshold, anti_flicker for Bloom; Do you have more information about these besides the comments in your dropbox file? Another thing I am wondering about: Let's say I have 4 files that contain only their named effects: 1. KS3P_AmbientOcclusion.cfg; 2. KS3P_Bloom.cfg; 3. KS3P_ColorGrading.cfg; 4. KS3P_AntiAliasing.cfg; Would KS3P use only one of them? Or would it effectively 'merge' them to use each effect?

@4x4cheesecake I'm curious, where'd you find information regarding those settings? Many of those values I have not seen in the Unity Docs.

Is anyone else seeing the following exception in their log? NullReferenceException: Object reference not set to an instance of an object at scatterer.Core+MainSettingsReadWrite.saveCoreMainSettingsIfChanged () [0x00000] in <filename unknown>:0 at scatterer.Core.saveSettings () [0x00000] in <filename unknown>:0 at scatterer.Core.OnDestroy () [0x00000] in <filename unknown>:0 I only see it when I exit the game (makes sense considering it happens on scatterer.core.ondestroy) and it doesn't appear to have a big impact so far. Re Tsunami bug: Though the tsunami is gone, saving and loading that save in the space center still shows the aftermath of said tsunami for me -> KSC buried under dirt. These two minor glitches together do make me wonder whether something's up with my install or scatterer itself. I would appreciate it if anyone could chip in. Edit: I looked through the thread and could not find an answer to the following, so here goes: What is the preferred method for custom configurations of Scatterrer? Do I MM @scatterer_config after it or do I create a separate standalone config and add something to let scatterer know it exists? I'm mainly looking to save my settings in a personal folder so I can drag&drop it in new installs.

Just a heads-up. The following parts have a typo in their .cfg (subcatagory instead of subcategory): restock-antenna-stack-2 restock-antenna-stack-3 restock-relay-radial-2 restock-reactionwheel-radial-1 restock-goocanister-625-1 restock-materialbay-radial-1 It's probably harmless, but I figured I'd mention it. Edit: If anyone knows what subcategory is/can be used for I'd love to know.

Wouldn’t it be kinda what you mean if you use Deadly Reentry with ~50% heating?

I think it says “here’s the amount you get (and this is what was added to that)” Edit: Checked, it does.

Like most things in life: You probably could, but since you're asking that question, you probably can't. (yet) It'd really depend on what the conflict is.

@Sigma88 cheers. I didn’t know MM used to not log all the patches, that was indeed why I suggested filtering earlier. Functionally there is indeed 0 difference. There are a couple more FINALs in JNSQ cfgs that would be better as LASTs. I checked because I couldn’t (neatly) undo a Kopernicus collider addition as suggesties by Galileo unless I’d race to FINAL too with zzzzzs. (It was spamming my log) With regards to Tweakchutes: its a nice fix for a stock oversight, but I don’t think it’s a good idea to just apply it to everything with a parachute key because: a: people who are used to the stock behavior will wonder what on earth changed their chutes; b: mod-added chutes will/can also be affected which would make TweakChutes a ‘bad neighbor’. Its similar to my dislike for the ReStock+ nerf to the Oscar B tanks: the change makes sense, but nobody will expect this change to be made by a parts pack/planet pack. Having said that, I don’t think I’ve ever noticed chutes doing full deploy before partial, so that + the fact that I know where the change came from means that I don’t mind. @Galileo cheers. I’m glad it doesn’t negatively impact the game. By the way, since we’re on the topic of “didn’t realize x had changed”: the JNSQ ResearchBodies CFG has the log mention a warning that planets were ‘discovered’ using “pre-1.5 method(s)”. I don’t know if it’s related to RB nullreffing and not updating the discovered planets in the difficulty menu, but since RB throws less errors without JNSQ I think it may be. While I understand your feelings I hope you realize that I like spending my free time on stuff like this about as much as you like listening to me spending my time in this way.

Is it possible to have the Air without the death? I like the added stuff to provide for my kerbals, but I enjoy annoyed/napping kerbals more than dead ones.

Yours still has FINAL, and NEEDS[TweakChutes] which really don't have a place there.