[1.5 - 1.10] Kerbalism 3.11

[king of nowhere]

8 minutes ago, Jofe said:

I'm not against the concept. Just wishing there was another way that didn't involve bringing/producing more nitrogen for shorter trips. Which reminds me of something I forgot to mention yesterday, why do you keep using nitrogen while you're on eva? I understand using it to regain pressure on the capsule after someone goes in or out, but the problem (for me at least) is that it's constantly used while there's a kerbal on eva, but the second they go back in it stops. Do they forget to close the door or something? (I mean, they're kerbals so maybe the do)

this one is a bug; it's been there for years. my subsequent exchange with gotmachine was about that.

shutting down the pressure control generally prevents that bug from doing more harm

[Jofe]

38 minutes ago, king of nowhere said:

this one is a bug; it's been there for years. my subsequent exchange with gotmachine was about that.

shutting down the pressure control generally prevents that bug from doing more harm

I thought that was a different issue. Good to know. Thank you.

[N70]

On 5/24/2022 at 1:59 PM, Gotmachine said:

Unless some savior step in to put its hands in that mess, no.

the time I spent working on this mod is why I hate Unity nowadays

[R-T-B]

On 5/24/2022 at 10:59 AM, Gotmachine said:

Unless some savior step in to put its hands in that mess, no.

So I take it Kerbalism 4 is on hold or am I misunderstanding you?

I'd offer to help but Kopernicus is just about my sanity limit...

Edited May 27, 2022 by R-T-B

[SiCaRiO31]

1 hour ago, R-T-B said:

So I take it Kerbalism 4 is on hold or am I misunderstanding you?

I'd offer to help but Kopernicus is just about my sanity limit...

I think he is talking about 3.11

[DKShang]

I have a question regarding oxygen production. How many Kerbals can one chemical plant running Sabatier and one chemical plant running water electrolysis support producing oxygen? I had a ship with 4 Kerbals and set up my system as outlined in the "How to recycle O2 and Water" guide. The oxygen produced was not able to sustain the full crew and I cut the mission short. Now I am trying to figure out where my mistake lies. Did I place too high a demand on the system with a large crew or did I setup the system incorrectly?

[king of nowhere]

2 hours ago, DKShang said:

I have a question regarding oxygen production. How many Kerbals can one chemical plant running Sabatier and one chemical plant running water electrolysis support producing oxygen? I had a ship with 4 Kerbals and set up my system as outlined in the "How to recycle O2 and Water" guide. The oxygen produced was not able to sustain the full crew and I cut the mission short. Now I am trying to figure out where my mistake lies. Did I place too high a demand on the system with a large crew or did I setup the system incorrectly?

a chemical plant will sustain dozens of kerbals, maybe hundreds. they consume very little oxygen.

i bet you did not tell your chemical plant to dump hydrogen - or you told it to, but it wasn't dumping, because there's a bug with dumping. so your chemical plant was not doing water electrolysis, and not producing oxygen.

 

if i am right and it's indeed the bug, the only way I know of dealing with it is to refresh the "dump" setting on the chemical plant. the good news is that you only need to do it once for a process, and it affects the whole ship.

for example, you have 6 water electrolysis on your ship, all set to dump hydrogen. then you leave the ship, and when you reload it again, the hydrogen is not being dumped. then you only need to tell again a single one of those chemical plants to dump, and all 6 will dump regularly.

[king of nowhere]

having a lot of experience with long missions and part maintenance, I've noticed that the nominal duration does not correspond with reality.

Nominally, there are only two possibilities: some parts last long, and some parts last short. then there's high and low quality.

So, nominally, a high quality drill should have the same average malfunction as a high quality eclss. but in my experience eclss break quite often, I serveced them by the dozen, while in my current mission - which is now at 20 years in rss, equivalent to 60 kerbal years - I only had to service one single drill once. That's too much of a discrepancy to be a statistical coincidence.

Then eclss should last longer than reaction wheels, because the latter have short duration. and yet, i have to service reaction wheels less often than eclss. I have around 30 eclss in the ship, 60 drills and over 100 wheels. I also have to service antennas more often than reaction wheels. so, if having more of a part should make it more likely to break, i should break more wheels.

The part that gets broken more often are the nuclear reactors, they should last as long as the wheels, but I must service them every year and I keep finding some needing servicing - I have 12 big ones, which are really problematic, and 6 small ones, which instead never get broken, though they should have the same duration.

meanwhile, I have a bunch of low-quality rcs on command pods, i didn't bother making them high quality because i don't use them, but they never break. never need servicing, despite being low quality. So, if having less parts of a certain type ccauses more malfunctions, having only 4 rcs should kill them fast. Unless they are included in the attitude control group; but in that case, the nuclear reactors are included with a lot of fuel cells (which I do not use for electricity, but to turn monopropellant into nitrogen), so they should be protected too.

why is the nominal duration of parts not reflected in the slightest in their actual duration?

 

EDIT: similarily, why the "failures" tab often reports that a part needs servicing, when an engineer sent to check it will tell everything is ok - and conversely, a part may bust even though the tab says all is fine?

Edited May 28, 2022 by king of nowhere

[N3N]

On 5/4/2022 at 9:44 PM, Gotmachine said:

See https://github.com/Kerbalism/Kerbalism/wiki/PlayGuide-~-Signal#range-and-rate

But TLDR :
- Combining (same) antennas will only increase max range, data rate will stay unchanged.
- Having different antennas with high data rate and low data rate is a bad idea, as this will lower the max data rate to something in the middle.

Hey,

Is there a possibility to turn some antennas off?

Or a MM-Patch to add such a functionality?

 

 

On 5/9/2022 at 6:28 PM, N3N said:

Hey,

sorry for the maybe stupid question, but how can I see, which science (part) can be done on asteroids?

And can it be done only once or are there different "biomes"/asteroids, for example in JNSQ?

And doesn't anyone have an answer?

 

[king of nowhere]

1 hour ago, N3N said:

And doesn't anyone have an answer?

 

only thing you can do on asteroids is collecting sample.

At least until one year ago, didn't try with more recent versions

[N3N]

23 hours ago, king of nowhere said:

only thing you can do on asteroids is collecting sample.

At least until one year ago, didn't try with more recent versions

OK, thank you!

[N3N]

On 5/4/2022 at 9:44 PM, Gotmachine said:

See https://github.com/Kerbalism/Kerbalism/wiki/PlayGuide-~-Signal#range-and-rate

But TLDR :
- Combining (same) antennas will only increase max range, data rate will stay unchanged.
- Having different antennas with high data rate and low data rate is a bad idea, as this will lower the max data rate to something in the middle.

 Hey @Gotmachine,

Is there a possibility to turn some antennas off?

Or a MM-Patch to add such a functionality?

[Gotmachine]

1 hour ago, N3N said:

Is there a possibility to turn some antennas off?

Retracted antennas are disabled. But for non-deployable antennas, no.
If you search this thread, I think I remember someone made a MM patch a while ago to add a fake deployable module to fixed antennas, but I'm not sure this ended up working correctly.

[N3N]

On 6/6/2022 at 6:13 PM, Gotmachine said:

Retracted antennas are disabled. But for non-deployable antennas, no.
If you search this thread, I think I remember someone made a MM patch a while ago to add a fake deployable module to fixed antennas, but I'm not sure this ended up working correctly.

Hey @Gotmachine,

OK, thank you!

 

 

On 6/4/2020 at 12:59 AM, natsirt721 said:

Suggestion: Add a PAW item to disable non-deployable antennas. I have a station in LKO with a DTS-M1 and a bunch of service vehicles using the 16-S docked to it, and my data rate is pathetic because I can't turn off the 16-Ss. Not sure if this applies to the antennas in probe cores, but I wouldn't think so because they can't transmit science. 

Alternatively, don't use multiple antennas if one is enough to do the job (start with the highest power one, if that can't get through add the next strongest one, etc.) but that seems overly complicated.

On 6/4/2020 at 6:07 AM, Caradhtinu said:

 

On 6/12/2020 at 10:47 AM, Drew Kerman said:

 

Hey @natsirt721, @Caradhtinu, @Drew Kerman,

Did you find a solution?

 

(Because I didn't find a working solution. )

Edited June 9, 2022 by N3N

[king of nowhere]

 

4 hours ago, N3N said:

 Hey @Gotmachine,

Is there a possibility to turn some antennas off?

Or a MM-Patch to add such a functionality?

if it is a manned vehicle with some storage space, you can have an engineer remove the antenna and pack it away with eva construction.

on a probe, you can edit the file to break the antenna you want to disable, and then edit it again to fix it later.

yeah, imperfect solutions, but it's something

[kerbnub]

On 8/21/2021 at 11:08 AM, visssius said:

Hello guys!
So today while playing my new career with kerbalism and other mods I found a very wierd behavior with CO2. So let me explane everything.
I launched a "Sunrise" abitation module from Stockalike Station Parts Redux with no configuration, so there was no Scrubber for CO2, with Jeb inside.
Now... if I'm not mistaken the game said that it's unpressurised wich mean there is no air inside and I have to keep a spacesuit on. 
When I reached Orbit with Jeb... He started to get poisoned with CO2 even if he was with his suit and he had his own scrubber for CO2...
Now when I saw that I immediately took him out... and the scrubber on the suit started to pull out the CO2 from his spacesuit(wich is wierd)... but unfortunately it was too late and he died on the ladder of the little station...
So is that a bug? or do I have to configure something? I found later in the VAB there is "Habitat: enable" wich gives me atmosphere inside and when I set it "disabled" it disapears. Was that a thing I had to take care?
Is it even possible to just send someone in orbit with no scrubber on the module considering the spacesuit?

Thanks for the answers and sorry for bad english!

 

I recently started a new career with kerbalism and unmanned before manned and think I'm running into a similar issue. Due to the rearranged tech tree, the MK1 inline cockpit is the first crewed command pod I can get, and the tech required for scrubbers comes later in the tree. The cockpit is also listed as "unpressurized," but CO2 builds up in the cockpit to the point that my pilot starts to get CO2 poisoning. There seems to be no way to clear the CO2, even while flying low in the atmosphere, and it gets to the point that I need to EVA my kerbal to get its own suit to lower its poisoning levels back to 0 before flying again... but the cockpit CO2 levels can only accumulate, so I'd have to keep doing that for any longish flight. What's worse, I'm running KCT and using its whole vessel recovery feature, and it seems that the cockpit CO2 levels are saved and are not reset if I launch the same craft again.

[VMQ]

I am trying to find out a problem with a contract from Contract Configurator with Kerbalism where the check for CrewCapacity fails when crossing a certain altitude, somewhere around 2344m. On the launchpad, and during the early phase of the launch the "Support 4 Kerbals" condition is satisfied, but then it fails. I filed two issues, Contract Configurator issue 717  and Kerbalism issue 817 with further details. 

Does anyone have an idea where/why the CrewCapacity seems to be removed at around the altitude when the pressure or oxygen go away on the outside? See the video below, Kerbalism says all is good to support the crew.

Here is a video of one of those launches:

 

[king of nowhere]

I have a problem: some of my nuclear reactors are not working.

My mothership has 11 excalibur reactors, each one producting 3000 electricity, so it should produce 33000.

it's instead producing only 24000, and out of electricity.

trying to find the problem, i did discover three reactors that are just not working. here is one

you see, now it's stopped, and the ship is producing 24000 energy

and now it's running, but the ship is still producing 24000 energy. It's not broken or anything. The ship, obviously, has no problems with supplies - it has tens of tons of uranium, and it has storage space for xenon and depleted fuel too - not that it should matter, since it's on "dump" mode.

I checked the file, but I could not find any relevant difference in the "easy" parameters (status, broken, and similar) and the rest are too complicated. Anyone knows why this happened and how to fix it?

P.S. it may have been caused by some of those reactors getting broken (not-critically) in the past, and subsequently repaired. Already I had problems of broken reactors not working after they were fixed, but a reload always solved the problem in the past. Also, five different reactors broke on this ship, (well, six, but one was critical and was dropped, hence why I have 11 reactors and not 12), and only three are not working.

P.P.S. I probably could fix the problem by copy-pasting into the saved file the data from another, working reactor. I am however afraid to break stuff, like, touching the data on where the reactor is placed on the ship.

In this code (spoiler for brevity) can someone tell me which part I should copy from a functioning reactor, and which part I should leave?

thanks to any who can help

Spoiler

PART
            {
                name = reactor-25-2
                cid = 4293602606
                uid = 4284391967
                mid = 378138747
                persistentId = 1653236367
                launchID = 23
                parent = 133
                position = -0.1012970358133316,-15.685274124145508,6.4000024795532227
                rotation = 1.86264515E-09,0.866025507,3.33066907E-16,0.500000179
                mirror = 1,1,1
                symMethod = Radial
                istg = -1
                resPri = 0
                dstg = 2
                sqor = -1
                sepI = -1
                sidx = -1
                attm = 0
                sameVesselCollision = False
                sym = 17
                sym = 76
                sym = 190
                sym = 249
                srfN = , -1
                attN = top, 133
                attN = bottom, -1
                mass = 15.5279999
                shielded = False
                temp = 115.23924685706677
                tempExt = 116.60095448308886
                tempExtUnexp = 4
                staticPressureAtm = 0
                expt = 0.5
                state = 0
                PreFailState = 0
                attached = True
                autostrutMode = Off
                rigidAttachment = False
                flag = Squad/Flags/default
                rTrf = reactor-25-2
                modCost = 1646800
                modMass = 7.76399994
                moduleVariantName =
                moduleCargoStackableQuantity = 1
                EVENTS
                {
                }
                ACTIONS
                {
                    ToggleSameVesselInteraction
                    {
                        actionGroup = None
                        wasActiveBeforePartWasAdjusted = False
                    }
                    SetSameVesselInteraction
                    {
                        actionGroup = None
                        wasActiveBeforePartWasAdjusted = False
                    }
                    RemoveSameVesselInteraction
                    {
                        actionGroup = None
                        wasActiveBeforePartWasAdjusted = False
                    }
                }
                PARTDATA
                {
                }
                MODULE
                {
                    name = RadioactiveStorageContainer
                    isEnabled = True
                    stagingEnabled = True
                    EVENTS
                    {
                    }
                    ACTIONS
                    {
                    }
                    UPGRADESAPPLIED
                    {
                    }
                }
                MODULE
                {
                    name = ModuleB9PartSwitch
                    isEnabled = True
                    stagingEnabled = True
                    moduleID = meshSwitch
                    currentSubtype = Open
                    EVENTS
                    {
                    }
                    ACTIONS
                    {
                    }
                    UPGRADESAPPLIED
                    {
                    }
                }
                MODULE
                {
                    name = Emitter
                    isEnabled = True
                    title = Radiation
                    toggle = False
                    radiation = 0.00029999999999999997
                    ec_rate = 0
                    running = True
                    radiation_impact = 0.00031583083319243146
                    stagingEnabled = True
                    EVENTS
                    {
                    }
                    ACTIONS
                    {
                        Action
                        {
                            actionGroup = None
                            active = False
                            wasActiveBeforePartWasAdjusted = False
                        }
                    }
                    UPGRADESAPPLIED
                    {
                    }
                }
                MODULE
                {
                    name = ProcessController
                    isEnabled = True
                    running = True
                    valve_i = 1
                    stagingEnabled = True
                    EVENTS
                    {
                    }
                    ACTIONS
                    {
                        Action
                        {
                            actionGroup = None
                            wasActiveBeforePartWasAdjusted = False
                        }
                    }
                    UPGRADESAPPLIED
                    {
                    }
                }
                MODULE
                {
                    name = Reliability
                    isEnabled = True
                    type = ProcessController
                    broken = False
                    critical = False
                    quality = True
                    last = 2044664692.5509927
                    next = 2182769438.3523374
                    last_inspection = 2044664692.5309927
                    needMaintenance = False
                    enforce_breakdown = False
                    running = False
                    operation_duration = 0
                    fail_duration = 0
                    ignitions = 0
                    stagingEnabled = True
                    EVENTS
                    {
                    }
                    ACTIONS
                    {
                    }
                    UPGRADESAPPLIED
                    {
                    }
                }
                MODULE
                {
                    name = ModuleB9PartInfo
                    isEnabled = False
                    stagingEnabled = True
                    EVENTS
                    {
                    }
                    ACTIONS
                    {
                    }
                    UPGRADESAPPLIED
                    {
                    }
                }
                RESOURCE
                {
                    name = ElectricCharge
                    amount = 0
                    maxAmount = 1500
                    flowState = True
                    isTweakable = True
                    hideFlow = False
                    isVisible = True
                    flowMode = Both
                }
                RESOURCE
                {
                    name = EnrichedUranium
                    amount = 399.99975516208349
                    maxAmount = 400
                    flowState = True
                    isTweakable = True
                    hideFlow = False
                    isVisible = True
                    flowMode = Both
                }
                RESOURCE
                {
                    name = DepletedFuel
                    amount = 0.013858149112876125
                    maxAmount = 400
                    flowState = True
                    isTweakable = True
                    hideFlow = False
                    isVisible = True
                    flowMode = Both
                }
                RESOURCE
                {
                    name = _Nukereactor
                    amount = 300
                    maxAmount = 300
                    flowState = True
                    isTweakable = False
                    hideFlow = False
                    isVisible = False
                    flowMode = Both
                }
            }

 

Edited June 24, 2022 by king of nowhere

[N3N]

Hey,

Could this bug be, because of Kerbalism?

 

[kerbnub]

What is the thinking behind higher reliability parts taking more mass as well as cost? Can the mass factor be edited globally or would I have to modify every part's config?

[king of nowhere]

58 minutes ago, kerbnub said:

What is the thinking behind higher reliability parts taking more mass as well as cost? Can the mass factor be edited globally or would I have to modify every part's config?

higher reliability parts are built sturdier, and that requires more mass. maybe they have thicker structural parts; where there are moving parts, they are bigger, to hold more stress. electronics is less miniaturized, or perhaps additional redundant components are already included.

it makes sense for most parts. perhaps antennas are the one exception I can think of.

[edusaraiva]

Hi everyone... I'm using the mod Smart Parts with Kerbalism and JNSQ and most of Near Future mods..... anyone knows if there is a way to make smart parts appear in the automation part from Kerbalism?
I want to make this work together with NF capacitor and Kerbalism.... the idea is to the automation to activate the NF capacitors only when below a certain % of the EC and recharge when 100% and return to idle until needed again.

[king of nowhere]

I'm using kerbalism with rss, and I am baffled by saturn's radiation belt. it's a huge 150 rad/h belt encompassing all the inner moons. even at maximum shielding, a crew would be dead in 3 hours. with only the spacesuit, in 20 minutes.

I'm baffled because it does not seem real. I can't find any hard data on how deadly those radiation belts would be, but wikipedia does describe saturn's radiation belts as "relatively weak".

is there a reason the radiation belts were modeled like that?

[tonimark]

the github section , one year without updates also no replies for current issues on github more than 3 mounths old, i am wandering is this life support mod dead? 

should someone else adopt it and we pick up alternatives?

Edited July 7, 2022 by tonimark

[Gotmachine]

35 minutes ago, tonimark said:

the github section , one year without updates also no replies for current issues on github more than 3 mounths old, i am wandering is this life support mod dead? 

It is effectively no longer under active maintenance since much more than a year.

37 minutes ago, tonimark said:

should someone else adopt it and we pick up alternatives?

Kerbalism has been a community project since a long time, there is no need for "adoption", but so far nobody had been interested in picking up the not very fun role of active maintainer.
I used to have that role, which consists in triaging issues and integrating contributions, doing some beta-testing, publishing releases, but I'm not interested in doing that anymore.

This is a very big mod covering many features, and it is used in many different ways.
There are multiple active config packs, as well as other mods relying on the codebase being stable. 
The project is getting minor contributions from time to time, but it needs someone to integrate them without breaking all that.
This requires basic coding skills and being familiar with how the mod is structured and used, and while there are a few people around that could qualify, they aren't interested and/or don't have the time for that.

I'm quite willing to help if someone motivated comes around, and I usually answer technical questions on the Kerbalism discord server.