Caradhtinu

Alright, if I understand correctly you want that, but without having to click so many times for every single RCS thruster, right? I think I can help with that I have a module manager script I copied from somewhere else in this forum @PART[*]:HAS[@MODULE[ModuleGimbal]] { @MODULE[ModuleGimbal] { %enableRoll = false } } That deactivates the gimbal of every single engine in the game to prevent it from going haywire on roll, but leaves pitch and yaw activated So I guess I can figure an equivalent script for your problem @PART[*]:HAS[@MODULE[ModuleRCSFX]] { @MODULE[ModuleRCSFX] { %enableYaw = false %enablePitch = false %enableRoll = false } } Just tried it and it seems to work. Every time you place a thruster on a ship, it starts like the picture Blaarkies posted You need to put that in a text file. Copy and paste onto Notepad or whatever, and give it a name finished in .cfg Say, something like rcsConfig.cfg. Then go to your game directory and put that file within GameData If you had any mods already, chances are you're done. If you were completely stock, you'll need to add the ModuleManager.dll there to GameData too

Seems to me like the best way to get back into the SoI you just exited. What shape is the sphere of influence anyway, I'm pretty sure it can't be a perfect sphere. There might be some chaotic math there

Usually staging, but today I found out Jeb snuck in a probe-controlled rescue ship. Made the rendezvous, got the rescuee to the hatch of the pod and couldn't get in because it was already occupied. As a punishment, made Jeb deorbit inside the derelict and jump off once the flames were out. Good thing Kerbin is so smol

Hi, was coming to report some bug. I crashed a ship and the game got incredibly slow. Not exactly frozen but the surviving parts were moving like a frame a sec. So I went to do something else, returned later to the computer and the debris was still moving, the kerbalism window said a science experiment was still biome «in space» But the game didn't crash, I just quit through the menu. The log was all spammed with this: [EXC 21:47:12.440] NullReferenceException: Object reference not set to an instance of an object KERBALISM.Lib.CrewCount (ProtoVessel pv) (at <c01b58fa9151425eac28bc1f9ddf5307>:0) KERBALISM.VesselData.FieldsDefaultInit (ProtoVessel pv) (at <c01b58fa9151425eac28bc1f9ddf5307>:0) KERBALISM.VesselData..ctor (Vessel vessel) (at <c01b58fa9151425eac28bc1f9ddf5307>:0) KERBALISM.DB.KerbalismData (Vessel vessel) (at <c01b58fa9151425eac28bc1f9ddf5307>:0) KERBALISM.Reliability.FixedUpdate () (at <c01b58fa9151425eac28bc1f9ddf5307>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) [EXC 21:47:12.619] NullReferenceException: Object reference not set to an instance of an object KERBALISM.Lib.CrewCount (ProtoVessel pv) (at <c01b58fa9151425eac28bc1f9ddf5307>:0) KERBALISM.VesselData.FieldsDefaultInit (ProtoVessel pv) (at <c01b58fa9151425eac28bc1f9ddf5307>:0) KERBALISM.VesselData..ctor (Vessel vessel) (at <c01b58fa9151425eac28bc1f9ddf5307>:0) KERBALISM.DB.KerbalismData (Vessel vessel) (at <c01b58fa9151425eac28bc1f9ddf5307>:0) KERBALISM.Reliability.FixedUpdate () (at <c01b58fa9151425eac28bc1f9ddf5307>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) So, not a big deal, but here it is in case it's useful Great mod otherwise

It depends. I guess you can right-click the shortcut you use to open the game, and select "properties" at the bottom. Within that folder, there's another folder called "saves". The file you want to edit is .sfs you don't need to worry about .loadmeta The .sfs are really big, just press F3 and search the current name of that kerbal (Edit) If you mean to modify them from C#, I suggest string Kerbal.crewMemberName from https://kerbalspaceprogram.com/api/class_kerbal.html

If you use or combine another mesh, remember a @ModuleDeployableAntenna{ %windResistance = some randomly high number That way you can use it to transmit during atmospheric flight w/o it breaking

I had a crazy idea @PART[SurfAntenna]:AFTER[zzzKerbalismDefault] { @MODULE[ModuleDataTransmitter] { @antennaType = INTERNAL } } Yes, it's very hacky but at least it stops that antenna from interfering with others. The bad thing is that if you have a plane that only has the surface antenna, it can't transmit science anymore. This way it's only useful for probe control.

This module manager patch seems to work for me. Just copy it in a text file called whatever.cfg within the GameData directory @PART[SurfAntenna] { MODEL { model = Squad/Parts/Utility/commsDish16/model position = 0.0, 0, 0 scale = 0.01, 0.01, 0.01 rotation = 0, 0, 0 } MODULE,0 { name = ModuleDeployableAntenna showStatus = false isTracking = false pivotName = seg2 windResistance = 99999999 animationName = antenna extendActionName = #autoLOC_6005056 // = Restart <<1>><<2>> retractActionName = #autoLOC_6005055 // = Shutdown <<1>><<2>> extendpanelsActionName = #autoLOC_6002400 // = Toggle <<1>> } @MODULE[ModuleDataTransmitter] { DeployFxModules = 0 } } I had to add a tiny hidden copy of the other early antenna because for some reason ModuleDeployableAntenna refuses to work if there isn't an actual animation in the mesh file for the pivotName to use. But otherwise works fine as far as I can tell. BTW, thank you hoover270, it works

Hi, I want to ask what is really the intended behaviour of upgrades. I think there are two approaches to them. Option A: As technology progresses, better hardware is available but also upgrades to earlier hardware that keep everything rouhgly balanced. Once you know how to make lighter hard drives you can put them anywhere. Option B: Only newer models can be upgraded. Old technlolgy is tried and tested, but also monolithic. The new models are more modular, designed with upgrades in mind. I personally like A better, but kerbalism right now uses option B. Maybe this was intended behaviour, but the layout of the upgrades along the tree seems to go better with option A. I started a new game, science mode and kerbalism as the only mod. Going to the R&D building straight away you can see the unupgraded stats of each item . I manually edited the savefile to have thousands of science points, unlocking the whole tree. Out of these three examples, only the large probe core has been upgraded. Clearly option B, but it strikes me as odd. The only way to have the unupgraded versions of some probes is to play career mode and not pay the upgrades that come earlier in the tree. The heart of the matter is in KerbalismConfig/System/ScienceRework/Patches-HardDrives.cfg // Applies upgrades to relevant parts based on their initial drive size. @PART[*]:HAS[@MODULE[HardDrive]:HAS[#dataCapacity[>2],~experiment_id]]:NEEDS[FeatureScience]:FOR[zzzKerbalismDefault] { @MODULE[HardDrive] //(code for applying upgrade here) } @PART[*]:HAS[@MODULE[HardDrive]:HAS[#dataCapacity[>16],~experiment_id]]:NEEDS[FeatureScience]:FOR[zzzKerbalismDefault] { @MODULE[HardDrive] ... Towards the end of the file, all those *Capacity[>something] can be changed to be "lesser than" instead. *Capacity[<something] switches everything to option A. Maybe it was intended like it is, but I like better the other way so I will keep mine edited.

Just to make sure, do you have "invert steering" set on that wheel? Sometimes that can wreck havoc as SAS tries to correct only making things worse. You may already know this, but for some reason the landing strip is bumpier than the surrounding grassland. When I have a twitchy plane I turn around and taxi away so I can takeoff from even ground.

There is a minor incompatibility with Kerbalism and the way it modifies the mystery goo and the materials bay experiments. The deal is that Kerbalism replaces the stock ModuleScienceExperiment with a module just called Experiment, here's how it looks in the save file: PART { name = GooExperiment cid = 4294422510 uid = 3031043241 mid = 2961929553 persistentId = 2899502642 launchID = 1 parent = 0 position = 0,0,0 rotation = 0,0.70710665,-0.707106888,0 mirror = 1,1,1 symMethod = Radial istg = -1 resPri = 0 dstg = 0 sqor = -1 sepI = -1 sidx = -1 attm = 1 sameVesselCollision = False srfN = srfAttach, 0,collider mass = 0.0573000014 shielded = False temp = 305.95995024898889 tempExt = 305.84427350630295 tempExtUnexp = 305.84353176691593 staticPressureAtm = 0.98752894990978901 expt = 0.5 state = 0 attached = True autostrutMode = Off rigidAttachment = False flag = Squad/Flags/default rTrf = GooExperiment modCost = 0 EVENTS { } ACTIONS { ToggleSameVesselInteraction { actionGroup = None } SetSameVesselInteraction { actionGroup = None } RemoveSameVesselInteraction { actionGroup = None } } PARTDATA { } MODULE { name = Experiment isEnabled = True issue = situationId = 50331649 didPrepare = False shrouded = False remainingSampleMass = 0 privateHdId = 3031043241 firstStart = False expState = Running status = Waiting stagingEnabled = True EVENTS { } ACTIONS { StartAction { actionGroup = None } StopAction { actionGroup = None } } UPGRADESAPPLIED { } } MODULE { name = ModuleSYPartTracker isEnabled = True id = 2899502642 TimesRecovered = 0 Inventoried = False stagingEnabled = True EVENTS { } ACTIONS { } UPGRADESAPPLIED { } } MODULE { name = HardDrive isEnabled = True hdId = 3031043241 effectiveDataCapacity = 0 effectiveSampleCapacity = 1 stagingEnabled = True EVENTS { } ACTIONS { } UPGRADESAPPLIED { } } } That remainingSampleMass represents the "mass of available goo to be exposed", in tonnes. The experiment can be run partially, and then in a different biome, but can't be run for more than "the total of one run". After that, a new goo canister is needed. If you recover a craft with a depleted goo canister and relaunch it right away, the goo won't work. Fine, that's intended behaviour. You can edit in the VAB, select in ScrapYard and choose to use a new part, KCT will correctly take some time in refurbishing the craft. But after rolling out to the launchpad again, it turns out the brand new part copied the whole Experiment module from the part that was replaced. So this is clearly a misunderstanding between mods, and I'm not sure whose fault it is or which mod should correct it. Maybe Kerbalism could take that remainingSampleMass out of the module, and turn it into a RESOURCE{} so that the "fill tanks" option in Kerbal Construction Time could "refill" the canisters. Or maybe ScrapYard could discard the MODULE[Experiment] despite it having a UPGRADESAPPLIED{} Anyway it's not a really big deal, a workaround is to remove the part in the editor and place a new one. It's just a nuisance when it had a lot of parts attached to it with very precise offsets to keep balance.

Hi, I found an "issue" where there's actually nothing wrong with Kopernicus but turns out a snippet of code can help make Kerbin look better. So recently I went back to playing KSP and downloaded version 1.9.1 It just looks great as we all know Latyer I thought I was up for a greater challenge, but not yet ready for RSS, GPP or JNSQ. So I looked for some way to give Kerbin axial tilt and make it twice as big. Found this old but still functional python script, Harder Solar System But, the horror, now Kerbin's atmosphere was lit all the way around. Must be some Kopernicus bug, ¿right? Wrong. I spent a couple hours trying to troubleshoot all the mods, just to find out that's just the way stock 1.8.1 Kerbin looks like. So I copied some RSS configs, fiddled a bit in Kittopia and came up with some code to get rid of that white ring @Kopernicus:FINAL { @Body[Kerbin] { %ScaledVersion { %Material { color = 1.4,1.4,1.4,1 rimPower = 3 rimBlend = 1.5 Gradient { 0.0 = 0.45, 0.55, 0.7, 1.0 0.3 = 0.2,0.15,0.05,1.0 0.6 = 0.0,0.0,0.0,1.0 1.0 = 0.0,0.0,0.0,1.0 } } } } } So just copying that in a .cfg file makes the atmosphere look like this. I guess those values can still be adjusted a bit, and maybe a similar workaround can be used for Laythe. But for now I'm just putting that info there in case it can help anyone. And I was also thinking, since 1.9.1 Kerbin looks so much better, would it be possible to take all that graphics data trough a Kittopia dump, so it can be used with 1.8.1 Kopernicus?