[RCS should follow Input Configuration]

Alright, if I understand correctly you want that, but without having to click so many times for every single RCS thruster, right?

On 7/5/2021 at 9:26 PM, Blaarkies said:

 

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

[Strange time-to-encounter anomaly]

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

[What's your most common KSP mistake?]

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

[[1.5 - 1.10] Kerbalism 3.11]

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

[Where the game is installed?]

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

[[1.5 - 1.10] Kerbalism 3.11]

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

[[1.5 - 1.10] Kerbalism 3.11]

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.

[[1.5 - 1.10] Kerbalism 3.11]

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

[[1.5 - 1.10] Kerbalism 3.11]

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
.

Spoiler

 

I manually edited the savefile to have thousands of science points, unlocking the whole tree.

Spoiler

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.
 

Spoiler

 

[What's wrong with this plane?]

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.

[[1.12.4] ScrapYard (SYD) The Common Part Inventory - v2.2.99.0-prerelease `<Project Zelda II>` edition [08 Jan 2023]]

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.

[[1.8.1-1] [PLEASE FORK ME] Kopernicus & KittopiaTech]

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

Spoiler

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?

Spoiler

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.

Spoiler

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?