Jognt

That doesn’t really do much. What decides when a patch is run is set by the timing in the patch (FIRST/FOR/BEFORE/AFTER/LAST/FINAL) You should probably use those wisely. You can technically run them all at FINAL, but you should avoid that where possible. If you’re changing another mod’s changes, use AFTER[thatMod]. It’ll also NOT run if thatMod isn’t present. If you want to make your own changes to stock parts, you should do so in FOR[myFolder]. If you want to do something to parts before another mod touches it, you can use BEFORE[thatMod], or if many mods may touch it, you could use FIRST.

ROCs are the new Breaking Ground surface features. To disable them you have to manually edit your save file, so do not do this before making s backup of your save. In your persistent.sfs save file, change the ROCseed = [string of numbers] to ROCseed = -1 Turning ROCs back on is a matter of replacing the -1 with what was there before. JNSQ comes with its own EVE configuration files. So it’s incompatible with other EVE mods (since technically it IS one).

I know the feeling my first use of github was a few weeks back maybe, and there’s a lot I don’t understand, but the PR thing is quite nice. (I did a grand total of three of them ) I understand how daunting it is though, so it’s fine either way. But if you’d ever like to do some git poking, I’m willing to share what little I know.

Wait... so I can build a big ship, give it engines, plonk my crafts on it (coupled/docked), and tell it to sail to the other side of kerbin/eve/laythe? This changes EVERYTHING. Edit: one trillion thanks to you!

Uhm, isn’t JNSQ 1.7+? ps. It might be a good idea to turn those mod lists into links. I’ve never used Career Evolution Contract Pack and thought I’d check, which I shall now do the usual way

Yeah I figured that may have been what was up (since they’re added to the brakes AG). If they’re in front of the CoM they also induce a strong pitch-down moment though. (Nice to keep your plane on the ground for braking admittedly) Unrelated to the slats themselves: would you consider uploading the mod (mostly the cfgs) to GitHub? That way I could submit PRs for fixes like cargobay occlusion checks, the slats center of rotation, and some others I’ve collected local fixes for.

So if I get this right the main problem is that KSP does not notify modules/mods about whether a part is moving or not? If so, maybe a feature request to Squad for that would be a good idea. Otherwise you’d have to write code that somehow manages to solidify parts while not solidifying stuff when it’s moving. Which is hard when you don’t know if movement is caused by joint flex or is intended.

If youre using the Kopernicus bandaid patch for FPS problems, that’s probably why. It gives bodies with no ocean an ocean. So it’d be there, but you shouldn’t be able to get to it

If you want to check what files/patches hit what parts, you can always open up your output log or MM log. It lists every patch and what part it targets like this: [LOG 12:23:22.053] Applying update CommNetAntennasInfo/Plugins/CommNetAntennasInfo/@PART[*]:HAS[@MODULE[ModuleDataTransmitter]:HAS[!#antennaType[DIRECT]]]:FIRST to SquadExpansion/MakingHistory/Parts/Pods/KV3Pod.cfg/PART[kv3Pod] That's a random line from my output log showing that the file CommNetAntennasInfo/Plugins/CommNetAntennasInfo.cfg contains a patch that affects the KV3Pod.cfg from the Making History expansion. As you can see it even lists what filter triggered the targeting. That should help you in tweaking your local Kerbalism install. Though it doesn't hurt to bring it up in the Kerbalism thread. Who knows, maybe you found a quirk/bug that they'd like to fix

@DMagic any plans to make the big map zoomable google/Apple/bing -maps style? It would make scansat feel even better to use. Also, I noticed physics time ratio shooting up while refreshing the map. Is it perhaps possible to do this in a separate process thread ‘on the side’? I figure it would speed up map-drawing while maybe not slowing down the main thread? Though I admit I don’t know the precise inner workings of KSP.

It’s not that NFE doesn’t work with Kerbalism. It’s that Kerbalism changes NFE which means Nertea can’t do anything about it. Since kerbalism changes NFE parts (they replace its modules with their own) it’s more a case of not liking what Kerbalism did to NFE parts. Which is best brought up on their side. Again, the behavior you see isn’t a compatibility problem, it’s what the kerbalism guys intended to change NFE’s behavior to.

Ask and you shall receive. I've added the biggest ones (the ones I made local MM patches for). Others are related to part weight vs stock which isn't really something you can solve without making them useless when you consider adding a US core and shroud. For example, the US2 battery has an insane charge vs. mass ratio on its own. But it normalizes when you consider the mass of the added core/shroud. The only way to balance this would be to make the core/shroud mass-less, which is suboptimal in its own way. So I'll consider these to be "Just the way it is". Sidenote, US2 fuel wedges without core/shroud are amazing for small probes.. The low dry mass, though not really 'stockalike', really shows there.

@rdnode:has[@parent:has[#parentid[basicrocketry]]]:for[mymod]{ @parent:has[#parentid[basicrocketry] {} } something like that? (On mobile, so you’ll Have to properly capitalize/tweak it yourself)

You’re welcome. Thanks for the script and .exe!

Yup, when attached they look like they would IRL. I noticed they are by default added to the ‘brakes’ action group though, so maybe it’s just due to KSP aero working differently. I’ll get some screenshots later to make sure I attached them properly just in case though. Edit: the way they work as I placed them means they do increase lift at an AoA of 30°+, but before that point they actually create downforce.

A question on the function of ‘leiding edge slats’ and a note on their placing: How are they supposed to work? I noticed that if I place them on the leading edge of my wings (curvy side up, pointy end forward, hinge in the back) and deploy them in flight, they generate quite a lot of ‘lift’ downwards. Ive been using them to plant my plane on the ground while braking/landing but from what I’ve read about real life flaps, they’re supposed to enhance lift? I added another set of slats to the same wing edge, rotated 180° so these aid in take-off/slow flight, and noticed that they don’t rotate on their center. This means it’s virtually impossible to balance them left/right properly. It’s nothing that AtmosphereAutopilot can’t handle, but I am wondering how I could fix/math it to be exact. So basically: do they work as ‘intended’ (brakes, downforce)? And are there precise coordinates for the ends of them to do some CFG offsetting?

Using Kopernicus I get around 12 FPS with a 4670k 4ghz and a gtx980. With both the CPU and GPU hardly doing work (KSP thread isnt even maxing 1 core..) so I'm guessing Kopernicus is getting stuck in an expensive Unity loop. Disabling Scatter and ROCs (savefile edit) massively improves FPS.

Are you using Kopernicus? If so, try disabling terrain scatter. Kopernicus received major updates for 1.7 so it’s got a few teething problems.

No. If it were, then nobody would have a working KSP. If you want them in zDeprecated, ask Squad. It’s their structure, we’re just along for the ride.

I didn’t experience this bug in AVP or JNSQ so I still recommend making sure everything and its dependencies are installed properly.

Wew.. I went from hitting 15GB used RAM and having to restart KSP (and removing IVAs) to using less than 10GB with IVAs! There's a slight stutter when it does its thing though, so I set the interval to 90 seconds to see what happens. "The best thing since sliced bread!" - Jeb "I can't believe it's not stock!" - Wernher Edit: Observations: It does cause quite a bit of stutter when changing scenes after being elsewhere for a while. But by the time it gets really annoying it settles back down so that's ok. I haven't encountered any "ESC not working" problems on Dx11 so far, and the RAM savings are very nice! One note though, after quitting KSP I noticed (once) I had firefox still running, and FF was slow as HECK. I'm guessing it got removed as well or something, because I had to restart it to get it to behave again.

For the FPS crash near/on bodies with no water, there’s a bandaid patch that works around the problem either on this or the previous page. I bolded the text so you should be able to skim and find it quickly. Regarding the similar fps crash on planets like JNSQ kerbin, I have no idea yet what is causing it, but its unplayable enough for me to try *stuff*. (Or quit playing. Whichever comes first) Could you elaborate on the issue (what happens when you start KSP/load your game) and when it started occuring? Im on mobile so downloading and checking the log isn’t happening at the moment. To those with solar panel problems: I have no clue. All I can say is ‘make sure you have the most recent Kopernicus and ModularFlightIntegrator’.

AFTER is equally specific as FOR. I suggest you check your output log or MM log so you can see the order of patching. AFTER[myMod] is literally right after FOR[myMod]. Lets say we have myMod and myMod2, here is the order of patching, assuming both are installed: BEFORE[myMod] -> FOR[myMod] -> AFTER[myMod] -> BEFORE[myMod2] -> FOR[myMod2] -> AFTER[myMod2] There are only passes for defined mods, so if there is no FOR[lolz], and no folder/dll called ‘lolz’, there are no BEFORE or AFTER passes for ‘lolz’. So again: Dont use FOR[myMod] unless you’re the mod author, since doing to will declare myMod as being present. So if you have a user patch with FOR[someMod] then someMod is declared present and patches with BEFORE or AFTER someMod will be run. So don’t do it. Edit: I may have misunderstood you. If you meant to always declare a pass, then you’re right. The ‘no pass specified’ pass is called legacy for a reason.

FOR[myMod] does two things: first it states ‘myMod is present’, second it states ‘run these patches in my turn’. AFTER[myMod] does two things too: first a conditional ‘only run me if myMod is present’. Second it states ‘run these right after myMod’s turn’. I don’t see why one wouldn’t just use AFTER[tweakscale] (or myMod) in all user patches. Because as long as tweakscale/myMod does its thing in its own turn (FOR) every AFTER user-patch will override tweakscale/myMod and not execute if the mod isnt present. Any patches running in the legacy pass (no specified turn/pass) won’t work if they depend on changing changes, but that’s ok. After all, patches without a specified pass that target a mod are bound to screw up something at some point so you may as well weed them out . edit: So DONT use FOR if you’re not the author of the defined mod pass, and replace FOR/NEEDS in user patches with AFTER.

Wait, so someone recently decided that using :FINAL in a distribution was still a good idea? Faith in humanity: lost.