Starwaster

I'm experiencing some serious issues with the More Servos parts, especially the Mk1 End Effector. It doesn't seem to be possible to create the type of double ended arm like found on the ISS (a Kanadarm2 so to speak). When both ends are docked to the same craft and the original base end is undocked, an exception is thrown [EXC 11:00:25.251] NullReferenceException: Object reference not set to an instance of an object Expansions.Serenity.BaseServo.AttachServoRigidBody (.AttachNode node) PartJoint.SetupJoint (Vector3 jointPos, Vector3 jointOrt, Vector3 jointOrt2, Int32 size, .AttachNode nodeToParent, .AttachNode nodeFromParent) PartJoint.create (.Part child, .Part parent, UnityEngine.Transform nodeSpace, Vector3 nodePos, Vector3 nodeOrt, Vector3 nodeOrt2, Int32 nodeSize, AttachModes mode, Boolean rigid, .AttachNode nodeToParent, .AttachNode nodeFromParent) PartJoint.Create (.Part owner, .Part parent, .AttachNode nodeToParent, .AttachNode nodeFromParent, AttachModes mode) Part.CreateAttachJoint (AttachModes mode) Part.Couple (.Part tgtPart) ModuleDockingNode.DockToVessel (.ModuleDockingNode node) ModuleDockingNode.<SetupFSM>m__4 (.KFSMState st) KerbalFSM.RunEvent (.KFSMEvent evt) KerbalFSM.updateFSM (KFSMUpdateMode mode) KerbalFSM.FixedUpdateFSM () ModuleDockingNode.FixedUpdate () Both ends of the arm detach and it floats away. Since the error seemed specifically linked to the servo code I tested with two Effectors joined only by an I-Beam. I've also tried an arm with the Effector replaced by a cubic strut a stock rotational servo and a WBI micro port which works in that the arm doesn't detach but starts spamming the log with exceptions. (I lost that log; will have to repro and get it to you) Also, the WBILightController is logging erroneous errors that there are two lights. I know for a fact that there FIVE lights.

Sounds correct to me. It's basically just a service module right? If it were really meant to be protected against reentry then they would have done more than just given it a high max temp. Shielding or thermal properties adjusted to actually protect it. What's the outer hull supposed to be made out of? Aluminum? (if aluminum then 1000 K is really a little high

Everything has its max temp balanced to something more sensible than stock where needed including the Nerv. A full heat bar with no damage or explosions means either something is broken somewhere or it wasn't really full or the temperature cheat was turned on.

Just the glow. I have no plans at this time to do separate texturing.

That's exactly what these config files do. They create new science just for probes and everything that has ModuleCommand and is vesselType Probe can do them.

If it's sandbox mode make sure you have the option turned on to apply all upgrades. And if it's career mode make sure you've researched the the upgrade

Update to KSP 1.7.3 There is no version of Kopernicus released for KSP 1.7.2

Never seen that since BG went live. What terrain quality are you using and have you tried to duplicate the problem on a stock installation?

No. Module Manager has come, done its business and gone long before you have a chance to load up any saved games or missions.

Those are used to adjust science situations; what you're considered to be doing when determining whether and how much science you get from experiments

Reducing frequency helps but it doesn't address the core problem which is that they aren't supposed to be there at all but are instead somehow being forced to be active by Kopernicus. It's not just the numbers it's that they are there at all. In my screenshot? You shouldn't see that. Never mind the quantity, they're not supposed to be there at all.

I'm glad to see that @SkyRex94s workaround is helping people but for myself, when I revert the various other fixes I had implemented for myself and try his ocean fix, I get the same thing as before which is Surface Features (aka ROCs) spawning inappropriately. Apparently (and as has been mentioned) he issue I see isn't the same as what other people have experienced but nevertheless this is a serious issue for upscaled systems and the more they are scaled up the worse the problem is. In this shot the Mun looks like it has measles (hint: at this distance and this speed those things should not be there at all) So the only remedy (at this time) for this problem is custom terrain quality settings and reduction of ROC frequency

Also the sun... don’t add oceans too the sun.

I will never EVER tell anyone to directly edit a part's cfg file. You create a cfg file somewhere in your GameData folder or one of its subfolders. Edit the cfg file and paste the following into it. Replace YOUR-PART-NAME-HERE with the name of the part. If you want to do that to more than one part then separate the part names with a | i.e. @PART[part1|part2] @PART[YOUR-PART-NAME-HERE] { MODULE { name = PartStatsUpgradeModule showUpgradesInModuleInfo = true UPGRADES { UPGRADE { name__ = Spaceplane.Ceramic.TPS description__ = This part can withstand shallow reentries now. IsAdditiveUpgrade__ = true PartStats { cost = 1000 mass = -0.1 maxTemp = 850 emissiveConstant = 0.85 thermalMassModifier = 1 skinMaxTemp = 2706 skinThermalMassModifier = 0.436 skinInternalConductionMult = 0.0000105 skinMassPerArea = 0.815 } } } } MODULE { name = ModuleAeroReentry leaveTemp = True maxOperationalTemp = 450 // this value should be replaced with the 1.25m initial values skinMaxOperationalTemp = 450 // this value should be replaced with the 1.25m initial value UPGRADES { UPGRADE { name__ = Spaceplane.Ceramic.TPS description__ = This part can withstand shallow reentries now. IsAdditiveUpgrade__ = true skinMaxOperationalTemp = 2706 } } } }

@PART[*] { %rigidAttachment = True } There's also an option to force the tweakable to be visible in flight mode as well. @PHYSICSGLOBALS { %showRigidJointTweakable = Always }

It's possible to put a round dome type on that (I think I used the top slider) and get yourself a flying saucery looking thing. Not sure how useful that is but it looked neat.

@4x4cheesecake Are you using any non-stock planetary systems with Kopernicus? I don't believe just installing Kopernicus is going to be sufficient. You probably are going to need another planetary pack such as SigmaDimensions + rescaled Kerbol or JNSQ. Real Solar System has yet to be officially updated for 1.7.3 and I suspect it will also have to have surface features (ROC) defined for it and when it does we'll probably see issues there too.

Advice: Read the past few pages

Quite a few modders around here will tell you to avoid foreach like the plague, at least when it's being done every FixedUpdate / Update. But is that code even executing for a body which has no rings? (or even if it does; it would be a foreach on an empty list)

There used to be a couple of liason people for Curse on these forums but I don't know Curse currently has anyone active here. I'd send feedback to CurseForge directly and tell them it needs updating.

The tank part gets patched with the upgrade patch in the second part. You research the update in the R&D (or if it's in Sandbox and you have the option selected to automatically apply all updates)

You have two ways of doing it. For the actual mk2 parts I would patch the actual part with the appropriate values (this is what I use for the mk2 cockpit @PART[mk2Cockpit_Standard] { @maxTemp = 850 @emissiveConstant = 0.85 @thermalMassModifier = 1 // if thermalMassModifier ever changes then skinThermalMassModifier must be multiplied by the same value %skinMaxTemp = 2706 %skinThermalMassModifier = 0.436 %skinInternalConductionMult = 0.0000105 %skinMassPerArea = 0.815 MODULE { name = ModuleAeroReentry leaveTemp = True } } For the tanks you could do the same but what I would do instead is leave their inital properties as is and instead use the upgrade system as follows MODULE { name = PartStatsUpgradeModule showUpgradesInModuleInfo = true UPGRADES { UPGRADE { name__ = Spaceplane.Ceramic.TPS description__ = This part can withstand shallow reentries now. IsAdditiveUpgrade__ = true PartStats { cost = 1000 mass = -0.1 maxTemp = 850 emissiveConstant = 0.85 thermalMassModifier = 1 skinMaxTemp = 2706 skinThermalMassModifier = 0.436 skinInternalConductionMult = 0.0000105 skinMassPerArea = 0.815 } } } } MODULE { name = ModuleAeroReentry leaveTemp = True maxOperationalTemp = 450 // this value should be replaced with the 1.25m initial values skinMaxOperationalTemp = 450 // this value should be replaced with the 1.25m initial value UPGRADES { UPGRADE { name__ = Spaceplane.Ceramic.TPS description__ = This part can withstand shallow reentries now. IsAdditiveUpgrade__ = true skinMaxOperationalTemp = 2706 } } }

Shielded covers or doors

@vossiewulf Even without the Deadly Reentry icon in your tray, there's just something about a spacecraft bathed in the reddish orange glow of reentry that brings a smile to my face first thing in the morning with a cup of coffee in my hand! JNSQ Kerbin reentries are on average going to be a bit ... toastier than over stock Kerbin btw.

It has been recently brought to my attention that I caused distress with my loathsome utterance of the words 'inverse kinematics' I humbly beseech you all to forgive this grievous transgression. I go now into exile in the wilderness no doubt to die a lonely death at the claws and teeth of some fearsome predator.