Starwaster

Because every PartModule can modify the cost of the part it is on. It does this by reporting a cost delta and there is no sanity checking to ensure either a minimum cost nor a negative cost. Literally every plugin mod potentially is modifying the cost of the part and the more of them you have the more likely that stuff like this is going to happen. (this is done by calling GetModuleCost() on the PartModule in question assuming it implements IPartCostModifier. The only information available to GetModuleCost is the base part cost from the prefab and if the part has resources on it it does not take into account the fact that the player may have adjusted those resources)

All information required is stored on the newly created vessel on only two fields. Everything else can be extrapolated. Again you're overthinking this as being harder than it is. There's nothing particularly difficult about it but you do have to do some thinking.

Wrong.

Because MJ was never 'trained' to recognize Real Chute parts as parachutes. It looks for a specifically named module (really a class) called ModuleParachute and Real Chutes implements its own classes that MJ doesn't recognize and likely would require reflection to trigger. It's not impossible to code for (not even hard really unless you're like me and just absolutely hate having to use reflection because you hardly ever use it and so don't remember how because it's been months since the last time you used it...) it's just that nobody has ever gotten around to writing the code required to make it happen.

That sounds like MJ being unable to calculate thrust or deltaV. If it cant determine those then it has to default to starting at node

It depends on if you actually made use of new features that aren't supported in the most recent Monodevelop release. The latest Monodevelop is actually up to date in that regard in the source but there are no publicly available builds of that code. There are also downloadable packages add compatibility and I have successfully used them in compiling mods that used otherwise unsupported C# features. (MJ2 for example) So there are still options open for Mono users. It's not really a big deal sticking with it over VS.

Technically speaking you could but why??? i can't even...

Then you've probably got a bit of a learning experience ahead of you. For editing and compiling the source you're going to need something like Monodevelop or Visual Studio by Microsoft, both of which are free. Or rather, there is a free version of VS but you have to apply for a license. (basically have to register with MS is all it is). I prefer Monodevelop but it is no longer in development and the last version didn't support certain features in the latest C#.

You don't open the DLL. You download the source, edit the source and compile it into a DLL. (you CAN decompile a DLL, which is the closest I can think of to 'open the dll', but that isn't what you want to do) https://github.com/severedsolo/OhScrap

I'm unclear on exactly what you're saying happens. Do you mean that the ports are unable to dock to one another? Or undock? Or does something else happen such as the ports moving around? And does this happen in the SOI of any planet? (when it comes to coordinates, it really shouldn't matter if it's scaled up or not... unless you're talking about heliocentric space where the distances are really far apart in RSS at the more distant orbits. So I could see coordinate accuracy being an issue for the more distant planets)

I'm 'mouthing off' on the basis that I am one of the developers for Real Fuels and RF is running on MY system for any particular new KSP update long before YOU get the official RF release for that version. And I use RF Stockalike engine configs to boot. And yes, it works with RF Stockalike installed to GameData folder. Whatever happened to you had nothing to do with what you said.

No you don't. That's just plain wrong. If you got different results when installing it to Real Fuels then you carried out the installation incorrectly the first time in a manner that had nothing to do with whether or not you installed it in the RealFuels folder. The RFS patch doesn't work that way. It probably CAN be installed there without deleterious effect but you shouldn't do so and you definitely shouldn't give that advice to people. I apologize if this part comes out as harsh but you have an incorrect understanding somewhere of how this works and you shouldn't give advice on that basis because sooner or later you are going to end up seriously screwing up someone else's installation in a manner that you will not be able to undo and it will cause them and whoever DOES end up helping them undue aggravation.

Ok yes, that is a known issue in 1.4 (or one of the minor 1.4 updates, I forget exactly when it was introduced) and to correct it you should do what @JadeOfMaar said and install that mod.

What's a Hexa-Girder? I don't see anything like that... am I missing an update?

Then increase ambient lighting

This is in BonVoyageModule.cs The five lines that actually handle the orientation come from HyperEdit. The commented out section was something of my devising and it probably should have worked better I think but I was having trouble getting the vectors right so I went with something a little more proven. Because it's using the terrain normal it should handle things like hillsides if they're shallow and not too uneven but with stock BV the vehicle probably can't get to really steep or uneven terrain as it probably pathfinds around them. The commented out section public override void OnStart(PartModule.StartState state) { if (HighLogic.LoadedSceneIsEditor) return; GameEvents.onVesselGoOffRails.Add(OnVesselOffRails); // wayPoints = PathUtils.DecodePath (pathEncoded, this.vessel.mainBody); } private void OnVesselOffRails(Vessel v) { if ((object)v == null || v.isEVA) return; double altitude = GeoUtils.TerrainHeightAt(v.latitude, v.longitude, vessel.mainBody); if (v.altitude < altitude + v.heightFromTerrain) v.altitude = altitude + v.heightFromTerrain; try { Quaternion rotation; Vector3d from = vessel.vesselTransform.up; Vector3d to = GeoUtils.GetTerrainNormal(vessel.mainBody, vessel.latitude, vessel.longitude, altitude); rotation = Quaternion.FromToRotation(from, to); vessel.SetRotation(rotation); /* Quaternion rotation; Vector3d forward = vessel.vesselTransform.forward; Vector3d up; if (vessel.Splashed) up = vessel.mainBody.GetSurfaceNVector(vessel.latitude, vessel.longitude); else up = GeoUtils.GetTerrainNormal(vessel.mainBody, vessel.latitude, vessel.longitude, vessel.altitude); rotation = Quaternion.LookRotation(forward, up); //rotation.SetLookRotation(forward); vessel.SetRotation(rotation); */ } catch (Exception e) { } finally { } vessel.UpdateLandedSplashed(); }

Don't think I pushed it to my branch on github. I'll paste it here this evening or push the whole branch for perusal.

If you have Real Fuels (and possibly also Realism Overhaul or certain other RF engine packs) installed then your tanks might need ullage management. (i.e. use RCS or ullage motors to settle the tanks) If you do have RF installed you will know if your engines cannot be stably ignited because their staging icons will be yellow (risky) or red (completely unstable). MJ detects those mods and will wait until the engines are stable before firing. This behavior is configured under Utilities and there is also an option there for MJ to automagically use RCS to settle the tanks, IF RCS is enabled. Or, you use the Mun's SOI for a boost and save some DV....

oh you know what, I forgot that I was also running a customized BV that rotates the rover... I had totally forgotten I did that. I thought it was World Stabilizer doing it

I got nothing...

Ok so you installed it through CKAN along with RO. I don't know what you are talking about with regards to the rest. I.e. mark I-IV, dunno what that is and classic/high pressure are NOT tank types, at least not as defined by Real Fuels or RO. You might be referring to 'highly pressurized'...?... which appears in the notes for some tank types but it is not itself a tank type. Make sure the part you are looking at is titled Tank [Procedural] - if not then look for that in your inventory.

Procedural Parts does let you select tank types though it is not included with Real Fuels so if you didn't download and install it separately then you don't have it.

@Nertea FYI, skinHeatConductivity and skinThicknessFactor don't do anything for DRE anymore; those date back to when DRE had implemented a skin/internal system back in KSP 1.0. They won't harm anything but they are no longer used for anything since KSP implemented their own skin system. (skinThicknessFactor is sort of duplicated by skinMassPerArea IIRC or manually adjusting part and skin thermal mass...)

You can only choose a given tank type if the part's configuration file was written to allow that tank type. With the last update, the main difference between default and cryo is that cryo has 10 free layers of MLI that you don't see in the editor. Those 10 layers stack with any MLI that you add, so at the end it's added+10