Starwaster

I put together a proper release for Procedural Parts on my Github repository so that people don't have to mess with dropping the dll in. If you already grabbed the one from my dropbox link then you don't need this. Also notified linuxgurugamer so he can update CKAN https://github.com/Starwaster/ProceduralParts/releases/latest

You're right, I wasn't aware there was a dev of KJR out there anywhere

Correct, just copy and paste it out of my message into the ModuleJettison in the config.

As far as collider issues, it's a matter of using multiple simple parts (rectangles or squares) for the collider, but that's probably not useful to you dealing with someone elses model. About disabling the fairing, can you clarify please? You mean as in having the shroud disabled without having to disable it in the VAB? Or do you mean something else? If you mean to hide it from the start, try shroudHideOverride = True If you want to leave it on but disable decoupling, try decoupleEnabled = False

It was 'fixed' because of a few players (actually maybe as low as one player) complained that jettisoned fairings were destroying their craft. IIRC they insisted on jettisoning in a way that would jettison the fairing at the same time as they decoupled (there was actually a choice in the matter at that time) which naturally resulted in the fairing bouncing back into their engine. I think it was isFairing that controlled that and if it's set to false then it USED to stay with the engine until jettisoned and if true then it would detach with the decoupler instead. I don't know if it is still possible to do that; for instance I don't know if it was only fixed in the configs or if they actually changed that functionality in the code as well.

OK spoke to ferram4 about stuff and he says we don't even really need to call FAR's density methods anymore. Things we would have needed it for are handled in stock anyway so I'll change it to just rely on stock even if FAR is present. In the meantime, if you do have FAR and are having chute issues, download the dll that I linked to two posts up and that should help. I think. Big maybe there. Also, ferram says that KJR is fine for 1.2.2 as is without an update.

@Jikahn @Freds Here, try downloading this and copy it over your existing RealChute.dll file (GameData\RealChute\Plugins) https://www.dropbox.com/s/5a5ugsjv2wc1vdl/RealChute.dll?dl=1

Something's bothering me though.... I looked at the FAR method that I'm calling to get density and it's the same one FAR uses when it displays density in its GUI. If it's spiking then I'd expect the GUI to display that as well and it's not. Might be something wrong in how I'm using reflection to call the value but I can't look into it right now for the aforementioned reasons. If I still have power tonight I'll take another look at that. No, I take it back.... on further investigation, it's working the way it should. Density values I get back are within expected range... most of the time. Just under certain circumstances is it off.

@Jikahn, duplicated your descent with a special debug version of Real Chute and found FAR returning massive atmo density spikes on the way down. The amount of drag applied to the chutes depends (naturally) on density so it's no wonder they're tearing things apart. Going to have to lay this one at Ferram's doorstep but I don't know when I'll be able to create an issue for it. Massive storms inbound and I could be without power in a few hours. Very busy preparing for it. (Please note that the only compatible version of FAR is a development version.... I keep saying this people, mods that aren't updated or development issues you have to expect this)

@AlamoVampire Sorry for your loss I definitely know what it's like having lost my Melificent just over two years ago now. And working at a cat sanctuary, there's been several cats that I've grown attached to that I've had to say goodbye to as well as two dogs in the past ten years...

I'm not saying to call any of RF's methods. Look at what that code does. That's how you read a resource's density. (or any other field it has). Those are stock classes and methods being referenced in GetDensity()

What, you mean programmatically? You want the density of a resource? https://github.com/NathanKell/ModularFuelSystem/blob/d5dea57ef17b9653e409e9145e81d58c4b1c9c11/Source/Tanks/FuelTank.cs#L461-L468

Guys, I'm absolutely not going to touch any KJR related issues. The latest version is outdated and I will not test with it. I'll look into any FAR related issues but even there, latest version is a development version so it might have to wait until there's a final version. We'll see. But KJR, let me speak plainly here: Not a chance.

Pretty sure he never released them and I don't think they exist 'in the wild' anywhere. I would love for someone to prove me wrong though.

Yeah that makes sense. (about the plugin needing the icons in a hard coded location) And it makes Module Manager think that EL is installed so that satisfies the NEEDS for EL. (here's a fun fact: Using FOR[SomeMod] also automatically satisfies the NEEDS requirement for SomeMod even if it's not really installed) I don't see a really great solution here other than to retract what I said earlier and make EL and SC mutually exclusive in each other's configs for FUR. Clearly there's a reason why they lock each other out in CKAN.

Filtering out SC sounds reasonable for a workaround though it probably would be bad as an official fix (for those who might install SC + EL together legitimately) What is even IN that folder? I can't even tell from your logs and MM cache that it's even bringing anything to the party. Did SC just install an empty ExtraPlanetary folder?

It's that same Kerbetrotter nullref right when you added the big freight container object. @Nils277, you mentioned earlier that it was probably from a missing config; what's actually missing is the RESOURCE_DEFINITION for several of those resources. ModuleFuelTanks / RealFuels is susceptible to the same thing. Cross referenced the freight nodes with actual resource definitions and the ones missing are MetalOre, Silicates, Silicon, Lithium and DepletedFuel. Some of those are probably missing because of an outdated Community Resource Pack distribution, as in one of the mods that you reinstalled probably replaced your CRP install with an obsolete version. Reinstalling CRP right from the CRP repository would get you back Silicates, Silicon and Lithium: https://github.com/BobPalmer/CommunityResourcePack/releases I *think* DepletedFuel is from an outdated CRP and should be corrected in the FUR configs. (it's DepletedUranium now) No idea where MetalOre is coming from. Maybe it was also in the CRP and is something else now like MetallicOre (which is also in the freight configs).

Here's a new PhysicsGlobals patch to try: https://www.dropbox.com/s/pglbjmm5a0lchj0/PhysicsGlobalsTweaks.cfg?dl=1 The goal of it is to make skin-internal the dominant source of heat transfer instead of part-part. so you don't get megawatts worth of heat pouring into your poor little hydrogen tanks This is a fairly major overhaul of the thermodynamics system from a conduction standpoint that ultimately I intend to submit to Realism Overhaul. It's still early stages and may need some tweaking calibrating (contents of the file:) @PHYSICSGLOBALS:FINAL { @conductionFactor = 0.0250 @skinSkinConductionFactor = 0.12 // Skin-internal should dominate, not part-part @skinInternalConductionFactor = 8.3333333333333333333333333333333 @shieldedConductionFactor = 0.01 } So, you can see conduction factor has taken a major cut, 0.0250 down from 120 in stock or 5 in RO. The net result after all internal KSP calculations is that parts will have a conductivity of 250 W per m/2. Assuming aluminum as the major construction material though obviously, IRL steel would also be a major structural material. (and later, synthetics)

When you open the downloaded OPT file, it contains two folders and an installation instruction text file. Both of those folders must be copied to your KSP folder. (the folders are GameData and Ships) If you copied them to your GameData folder then parts won't load correctly. You can determine if you did that by looking at your KSP folder and opening up the GameData folder. If you find ANOTHER GameData folder inside then you have installed incorrectly. You must delete or move (not copy) that to your root KSP folder. (your root folder may be named something else like Kerbal Space Program. It is to that root folder that you needed to install the contents of the downloaded file)

That's it? That's all the information you're going to provide? well, you probably didn't install it in the right place

Huh, that's weird... that's only supposed to happen on April FoOls day....

It may not be the best place but just because you store it one place doesn't mean you can't also put it somewhere else. It's just data. There is no 'wrong place'

ScenarioModule is stored in the save file itself. The idea is using it as a go-between; you could store data there other mods could access. Truthfully though I haven't actually used it in that fashion before so I can't say it's any more or less feasible than putting that data in some other ConfigNode to be accessed. Just an idea.

@Snark @magico13 Maybe using ScenarioModule could come in handy here as a place to store crew assignment data?

might have to split it into two then then, one for each.