Jognt

In that case I recommend you ask a friend that knows how to deal with basic folder structures to help you out in properly extracting the .zip archive. The reason me and others couldn't see the parts were because we were trying to replace the stock stuff with them. If you're just adding the parts as completely new parts like you are, there shouldn't be any problem provided the .zip is extracted properly. Just to confirm, you've just extracted the .zip, and you've not created any seperate .cfg files right?

Assuming you haven't done anything yet, here's what to do: 1. Go to your KSP\GameData folder; 2. Go into the PartOverhauls folder; 3. Go into the GameData folder; 4. Select the PartOverhauls folder; 5. Right click it and click "Cut"; 6. Go back to your KSP\GameData folder; 7. Right click and click "Paste"; 8. When your PC asks you if you want to merge the folder, select yes or OK; 9. Again go into the Partoverhauls folder; 10. Select the Source and GameData folders; 11. Press the Delete key, or right click on them and select Delete or Remove; Now you should be left with a PartOverhauls folder containing a Parts folder in your GameData folder. Hope that helps!

Then there's your problem. Follow what I wrote in my previous post to fix it. The folderstructure that you want to end up with is "KSP\GameData\PartOverhauls\Parts" instead of your current "KSP\GameData\PartOverhauls\GameData\PartOverhauls\Parts". You can ignore that "Source" folder, that's not needed for using the parts. That's for modders who wish to tinker with.. well.. the source files. So you can remove it safely.

I'm gonna go out on a limb here.. in your gamedata\partoverhauls folder, do you see a Source and another GameData folder? If so, you were visited by the ancient archive-unpacking troll. From the PartOverhauls.zip file you have to take the PartOverhauls folder that is inside the PartOverhauls\GameData folder. If done correctly, you will only have a folder called "Parts" inside of your KSP\GameData\PartOverhauls folder. Let me know if that helps. In regards to ModuleManager, it should say so right in your KSP\GameData folder. It'll be in the name of ModuleManager[x].dll where [x] is the version of modulemanager that you have.

lol. I know the feel. Could you walk me through the steps you took while installing it? Also, what version of ModuleManager are you using?

If all you want is to have these parts *added* as extra parts, then I can confirm that Porkjets PartOverhauls works with 1.4.2. In terms of just replacing the stock parts models: Missing History should work for that. In terms of replacing stock models while keeping new stats/upgrades intact: I have it working on stock in my test installation, but not yet in my modded install, still looking for what's going wrong. Besides Porkjet's mk1 partoverhauls, I have no idea what works. Edit: Got a straight up replace working in 1.4.2 now. Thought I did something wrong in my modded install, but it was in fact me being stupid and not remembering I had to original parts hidden with Janitor's Closet.. Which meant that after replacing those.. I couldn't see them.. yeahhhh... I'm planning to look into: - Cleaning up what I have working now, it's not very.. elegant IMO; - Creating a version that replaces the stock stuff with stock stats while keeping upgrades (for sharing compatibility when upgrades disabled, but fun upgrades when enabled); - Creating a version that replaces stock stuff and removes upgrades, so basically what Missing History did; - Set this up so you can switch between any of them using Patch Manager; In the meantime, the following is what works in 1.4.2. It replaces the stock parts while keeping the upgrades, buffed stats, and surface attachability. It also contains the fixes done by @PocketBrotector on the previous page (is this ok? licenses and whatnot?). I would greatly appreciate feedback on this bit since this is my first attempt at a MM config. Save it as a .cfg file and throw it into the PartOverhauls folder to have it work. //Implement missing thrust upgrade for Heavy Rocketry node PARTUPGRADE { name = LVT-Turbopump-heavyR partIcon = liquidEngineT15 techRequired = heavyRocketry entryCost = 7500 cost = 0 // for display only; all parts implementing this will need a PartStatsUpgradeModule with cost = this. title = LV Series Thrust Upgrade //basicInfo = Whatever\nblah manufacturer = Jebediah Kerman's Junkyard and Spacecraft Parts Co description = Turbopump enhancements and other detail improvements lead to higher flow rates and thus higher thrust. } //Match thrust on Terrier boattail to standard version @PART[liquidEngine909_Boattail]:FIRST { @MODULE[ModuleEngines] { @maxThrust = 75 //was 80 } } //Correct description of Swivel Isp in Precision Propulsion upgrade @PART[liquidEngineT45,liquidEngineT45_Boat]:FIRST { @MODULE[ModuleEngines] { @UPGRADES { @UPGRADE:HAS[#name__[LVT-GasGen-precProp]] { @description__ = Isp now 325/265. } } } } //Correct description of Pug thrust in Heavier Rocketry upgrade @PART[liquidEngine303_Boattail,liquidEngine303]:FIRST { @MODULE[ModuleEngines] { @UPGRADES { @UPGRADE:HAS[#name__[LVT-Turbopump-heavierR]] { @description__ = Thrust now 33kN. } } } } -PART[mk1pod]:FIRST {} -PART[liquidEngine2]:FIRST {} -PART[liquidEngine]:FIRST {} -PART[liquidEngine3]:FIRST {} -PART[fuelTankSmallFlat]:FIRST {} -PART[fuelTankSmall]:FIRST {} -PART[fuelTank]:FIRST {} -PART[fuelTank_long]:FIRST {} +PART[mk1podNew]:FIRST { @name = mk1pod } +PART[liquidEngineT45]:FIRST { @name = liquidEngine2 } +PART[liquidEngineT30]:FIRST { @name = liquidEngine } +PART[liquidEngine909]:FIRST { @name = liquidEngine3 } +PART[fuelTank100]:FIRST { @name = fuelTankSmallFlat } +PART[fuelTank200]:FIRST { @name = fuelTankSmall } +PART[fuelTank400]:FIRST { @name = fuelTank } +PART[fuelTank800]:FIRST { @name = fuelTank_long } -PART[mk1podNew]:FIRST {} -PART[liquidEngineT45]:FIRST {} -PART[liquidEngineT30]:FIRST {} -PART[liquidEngine909]:FIRST {} -PART[fuelTank100]:FIRST {} -PART[fuelTank200]:FIRST {} -PART[fuelTank400]:FIRST {} -PART[fuelTank800]:FIRST {} Reason I used "FIRST" is to maintain compatibility with mods that change any of the stock parts. Reason I remove the stock parts completely is because if I didn't it would bug out and have inconsistent effects (basically what people were experiencing before with not all parts being properly replaced)

Thanks for the reply! Initially I skipped over the Missing History mod since I didn't have the DLC. But upon further inspection I'm thinking "Hmm.. Yes.. I can work with this...". I'll play around with it for a bit later and let you know what works.

@Kerbal101 After seeing several people mention that your v3 patch wasn't working for them, and then seeing it work just fine for you, I've been trying stuff for a few hours now. I give up, I have no idea what's going on and why. Problem in a clean 1.4.2 install with just PartOverhauls, Modulemanager, and your v3 integration file: Porkjet fuel tanks are fine and replaced. All the boattail engines, new engines, and the Swivel are fine. The Reliant and Terrier however are in some sort of in-between limbo where the porkjet version gets 'integrated' and then gets overwritten by stock again. I don't know what's going on anymore, I'd appreciate any input you can give in this situation. Example in VAB. Note the Reliant/Terrier having their old models and the Swivel being updated without problems, while the Terrier does have the internal fueltank and stock thrustlevel: Porkjet integration failure This is my GameData folder: GameData screenshot This is my output_log: Output log zip This is my 'integration' patch with your v3 code: Integration patch used zip And this is my MM ConfigCache in case it can help: MM ConfigCache zip On top of these problems, my main install has the problem where not just the reliant and terrier are in a weird limbo state, but the tanks themselves too, and some of the parts lose their mesh entirely, showing as just a green node when selected in the VAB. I hope I didn't miss anything. I'm tired from hours of checking all of the above files for a clue.

If only we were Kerbals that didn't require snacks or sleep.. We'd all be so productive

Cheers! Honestly, this bit of reasoning is one of the most important things when sharing mods (except for the download link). Without knowing what you changed and why, it's quite impossible for viewers to decide whether they agree with it and wish to make use of it. As for the "why I'm still here" question. Like I said, some things are a mystery of the universe. That comment was written by late-night Jognt who was annoyed because he couldn't sleep. Don't take it personally please :).

Agreed. I'm left thinking "Why does this exist? Why does OP think they're unbalanced? What balance did he try to achieve? Why am I even still in this thread?". OP, I'd appreciate it if you could answer the above questions, well, except for why I was still here.. That's a mystery of the universe.

You could either wait for Nertea to finish up his glorious work, or toss what I wrote below into a textfile and save it in a new folder of your choosing in your gamedata folder (I named it dockingPortLargeMini.cfg). It copies the senior port and then modifies it to have the proper 1.25m size (both in appearance and node size/weight/etc). Cost and location in the tech tree are the same as the regular clamp o tron. ps: I'm not sure on the etiquette of commenting with home-made stuff in other people's threads, so please let me know if it's not appreciated. Also, as a non-modder, I began toying with modulemanager a few days back, so while I think I did it right, I might not have. All I know is: it works :p. edit: or.. you could just use TweakScale.. just thought about that..

Me thinking: Oh, I actually made a small ModuleManager .cfg that gave me the 2.5m Sr docking port in a 1.25m format! Maybe I can make this guy happy! Me thinking: Oh my god, that looks so much better than what I did! D: well never mind then!

I just know how it works from the user's side of things. No idea how the backend works. The "Settings" drop down menu has the option to set "Compatible KSP Versions". I've got it set to show 1.4 and 1.3 mods too, since some of them work fine and it's easier to keep it all in one place (CKAN). For example, I installed parts of SETI earlier today via CKAN and installed your mod manually, but both would've been fine with CKAN. Atleast made it easier to remove afterwards since CKAN keeps track of dependencies better than I can :p. edit2: Before you ask why I removed it again: Don't ask, not sure myself. ADHD brains are annoying.

CKAN allows the user to set older KSP versions as compatible. It would work perfectly fine if you let them know about the older ubm version. You could add "Requires UbM by Yemo 1.3.1. Be sure to add 1.3.1 to compatible mods" to the description?

You may have noticed, but there's a typo in that propery "canSwithWithFullTanks". Unless 'swithing' is an actual term I don't know about yet. If it's just a typo in that comment, forget I said anything. Just figured I'd mention it.

Agreed. IMO the re-entry effects need a do-over after the particle engine change. I mean, it's not like re-entry is a rare occurrence in a space game xD.

Yikes! Guys, I know you want to fix all those bugs for us, but please, we'd rather have it "When it's done" than .. well .. "When it's not really done" Though it does seem like that contract debugging code is doing its job quite well. I'm guessing it's not supposed to do most of those checks?

I'm not a modder, but from what I've read so far that flag turns a part 'physicsless'. Meaning that its mass/drag is added to the parent part instead of being seperate. Most science experiments, the stock RCS thrusters, and lights have this flag set. Again, I'm not a modder, so I don't know how much of a difference it makes. I just noticed its absence compared to most of the stock stuff.

Check the previous page. He talked about this before, and he even provided such a +SSME config for someone that wanted it even though he didn't feel like adding it to his own mod.

Are these CFG files needed only for those with the DLC or are they needed for vanilla too?

@NESD After looking at the .cfg files I'm wondering if there's a specific reason for why you didn't use the "PhysicsSignificance = 1" flag?

Heya @Nertea I figured I’d drop in and give you something else to read than “great mod but have problem X”. Thank you a million times over for all the work and time you’ve put into this!

A note on Memgraph: While increasing mono padding will increase time between GC runs, it's still mostly a *diagnosing* tool. You can use the graph to check how much garbage is created per frame and see if that's in line with normal playing or if something else is creating excessive garbage.

Been trying to play 1.4.1 lately without KER and it really made me realize how much I depend on it! I've never really voiced this, but thank you so much for all the free time you have spent (and maybe will spend) on providing us with this insanely important functionality!