BudgetHedgehog

Hack it to run x64. Aside from that, nothing. There's Autopruner that stops the game loading things you already have procedural versions of, but aside from that, you're going to have to dig into the mods files. But that said, if the mod turns out to be complex and there's texture sharing going on with the different parts, there's not a lot you can do. The author has already done as much as possible to remove RAM overhead for you (thinking of the B9 HX parts - they all shared one texture or something so impact was negligible). If you want to reduce it further, you end up removing textures needed by the parts you want, which is what you don't want to happen. I think the KSO mod had just one file with all the different textures on it and then each part referenced a certain section of that file to use - there's no way you can change (save for loading the model itself and changing it there) or mod it to remove textures that parts you didn't want referenced. The upside of this kind of texture sharing is there's no duplicate textures, and that DOES increase RAM usage (a few versions ago, I think stock KSP had about 200MB or something of literally identical textures loaded. Remove them, nothing changes except for lower RAM usage). TL:DR - first two sentences.

Could you post the craft file for that? I believe they're still not attached to the decouplers.

Yo, gimme dat donate button...

From memory, that's a result of the city lights png file loading incorrectly. The fix was to convert it to png manually or use ATM. That was pre-1.0 though so ¯\(ツ)/¯

Cheers for doing this, 5th, as always. Although I now have Friday evenings off, I have to get up at 6am on Saturdays instead for a long shift and watching it real time that late at night means OWK would be a very sleepy chap at work Some good stuff in there, interesting that the 1.1 and U5 update may be split. I can't decide if that's good news or two bad newses, time will tell.

Post pictures please.

What's the problem?

Sounds like you're not attaching the boosters to the decouplers correctly. Make sure the cursor is actually on the decoupler when you're attaching the booster.

It can only rescale parts that it's been told about. If no-one tells it (i.e. creates a config), then it can't do anything. Ask the author to make a config for the parts, or even better, try making one yourself!

There used to be an optional field in the cfg called "CoMOffset = X, Y, Z" - I presume the XYZ are the co-ordinates of the intended COM location relative to the original. Stock Rebalance Project used it to move the CoM of the old Mk3 parts, for example. I presume it's still valid and will still work, you'll need to fiddle with the numbers though (don't go crazy, +/-5 or so will be more than enough. Also, only change one number as you only want to change the CoM on one axis. EDIT: I should type faster sometimes.

Nice one, cheers. One thing I never got round to asking you was in the changelog for Glauert, you said "Update win64 check code to MM method". What does this mean for users - does FAR not disable itself completely any more? Does it just show a warning in the loading screen? I looked at the source for Goldstein and Ferri, but I couldn't see any difference in the CompatibilityChecker files..

RSS just changed the horizon to blue rather than stock white and PlanetShine works fine in KSP 1.0.4. I think there's KittopiaTech as well that added rings to Jool. To have the full complete 100% KSPRC, you'll need those but if those changes don't appeal to you or you don't have the RAM to spare, you're fine to skip those mods.

Post your output log file (found in KSP_Data). Also, was this you? Because that's Windows and unless you mean the OS is 64bit, there's currently no official support for KSP x64 on Windows and you're advised to use the x86 version instead. But, if your OS is x64, that's fine. I doubt KSP would even run if the OS was x86.

2, No 3. Yes because this mod isn't updated yet. When it is to use dds textures, ATM won't touch it.

From memory, you have to force AA override in your GPU settings.

OK, no support will be given in this post - no, the fix doesn't address this as the crashes were not the direct fault of KW Rocketry and no compatibility issue between KWR 2.7 and KSP 1.0.4 exists. - - - Updated - - - CKAN questions belong in the CKAN thread.

Yeah. I may have misunderstood, Jacke mentioned getting it to work in stock, I was just letting him know it's already done.

Good, that's what OP (and I) want. It's easier to manage fuel flow and mass distribution around a vessel when A, you know the cargo isn't changing weight, B, decouplers and fuel lines are respected and C, you don't have to fiddle around with every tank to pump fuel around where you want it.

I think it is stock - the launchpad there is regarded as The Launchpad. If you park a vessel on it, leave to KSC, enter VAB and then try to launch something, it'll say you can't because the launchpad is already taken up by the vessel you parked on the other side of Kerbin Or at least, it used to. Haven't tried it recently though, but I haven't seen anything in the changelogs about it.

If it's fuel flow for the engines, is the fix as simple as changing that in the config? I'll grant you it's working as intended, but the intention is undesirable. It's like if they coded vessels to explode once they reached 80 km.

You guys might want to look at this then - Real Plume for stock.

Probably better to ask the Tweakscale guys.

Yes - parts mods 99% of the time do not break between versions, especially minor ones like 1.0.2 to 1.0.4. There's a hotfix around that patches some things like heat production and cost, but it's by no means required.

Yeah, it's known and apparently going to be fixed in the next version: It had already been reported, it will be fixed in the next release

Also possibly Procedural Fairings For Everything.