[1.12.5] Modular Kerbalism - Science Only Profiles

[theJesuit]

3 hours ago, Streetwind said:

I didn't even know there is supposed to be a geiger counter science part! I've just been using the one built into the probe cores.

I would instinctively assume they disappeared when you turned off the radiation feature... though then again, I don't know how the internals of Kerbalism work, perhaps they could be separated.

I found the config file you mentioned, thanks! Now I can ponder whether I want to turn it off for myself. It will depend on how annoyed I get with it.

I was hoping I could adjust the frequency or length of the events somewhat - I get a storm roughly every 30-40 hours, it feels like, and that feels a bit silly. Unfortunately there's only a binary on/off setting. =/

I was so surprised.  The new Geiger Counter looks better.

The frequency can be adjusted in the settings for each save.  I would love to adjust that as standard, but at least it can be adjusted in game, and even part way though a save.  In the advanced settings for a save Kerbalism has two tabs, i believe it is kerbalism (2)

 

[theJesuit]

@SheepDog2142

If you want to try multiplayer again in the KerbalismModularScience\System\ScienceRework\Tweakables folder, go through the cfg files and change all the ECCost = 0 which will remove ECchanges, apart from transmission.  Not sure if this helps, the transmission cost needs to be gotten rid of to help background processing, but and I don't know where to deal with that yet.

[SheepDog2142]

20 minutes ago, theJesuit said:

@SheepDog2142

If you want to try multiplayer again in the KerbalismModularScience\System\ScienceRework\Tweakables folder, go through the cfg files and change all the ECCost = 0 which will remove ECchanges, apart from transmission.  Not sure if this helps, the transmission cost needs to be gotten rid of to help background processing, but and I don't know where to deal with that yet.

Sounds great!

Yea the EC changes cause all sorts of issues. Im having to write a ton of patches for universal storage II to get the solar and power parts to work properly. 

[Streetwind]

22 hours ago, SheepDog2142 said:

Yea the EC changes cause all sorts of issues. Im having to write a ton of patches for universal storage II to get the solar and power parts to work properly. 

Can you share some of the issues you're facing? I'm currently observing some, but not all, of my OX-STAT solar panels outputting >10 EC/s instead of the stock 0.3 EC/s at full exposure. Needless to say that's a bit overpowered for the earliest, smallest panel there is. <_<;; And I'm wondering if Kerbalism is doing this intentionally for some reason, or whether something else is screwing with things.

(It's not the Modular Science Config though, that one doesn't even touch solar panels.)

[theJesuit]

44 minutes ago, Streetwind said:

my OX-STAT solar panels outputting >10 EC/s instead of the stock 0.3 EC/s at full exposure.

Are you using Kopernicus?

[Streetwind]

Yes, I am.

I did read about Kopernicus having issues with solar panels, and it putting some kind of bespoke module on the panels to replace the stock ModuleDeployableSolarPanel.

However, I did open my persistent.sfs and checked an affected vessel: the solar panels on it just have the stock module, along with Kerbalism's SolarPanelFixer module.

Are there still potential issues despite that? And if so, is there a known fix?

[theJesuit]

23 minutes ago, Streetwind said:

Yes, I am.

I did read about Kopernicus having issues with solar panels, and it putting some kind of bespoke module on the panels to replace the stock ModuleDeployableSolarPanel.

However, I did open my persistent.sfs and checked an affected vessel: the solar panels on it just have the stock module, along with Kerbalism's SolarPanelFixer module.

Are there still potential issues despite that? And if so, is there a known fix?

Maybe.  What planet pack are you using?  I'm wondering if it changes the sun luminosity

[Streetwind]

It shouldn't change the Sun, no. It's just Outer Planets Mod. No fancy add-ons, besides compatibility for Parallax Continued and True Volumetric Clouds.

For most of my playthrough so far, the panels have worked as I expected. It's only over the past 1-2 days that I started seeing issues. Both the weirdly overpowered solar panels, and the failure of background power generation from them (which I saw in the main Kerbalism thread is also experienced by some other people). For instance, a bunch of commsats I launched days ago still orbit Kerbin just fine and get power in the background, but several newly launched craft consistently run out of power as soon as I am not focusing on them.

It feels like the two are connected. Something messes with the solar panels, giving them not only the wrong foreground power output but also making them fail to work in the background.

A good indicator to tell apart affected solar panels from regularly working ones is the lack of a sun exposure and power readout in the PAW. Usually the panel should tell you a percentage figure of how well the panel is exposed to the sun, along with how much power it outputs. The "broken" panels, however, seem to have no functional elements at all in their PAW, apart from the default "aim camera" button in the "part" subtab.

 

...Now, while writing this I had the idea of looking through my savefile some more, and not only check an affected craft, but also compare it to an unaffected one. And bingo! I found something.

Here is the Module SolarPanelFixer from a solar panel that's working correctly:

				MODULE
				{
					name = SolarPanelFixer
					isEnabled = True
					editorEnabled = True
					nominalRate = 0.34999999403953552
					persistentFactor = 0
					state = Static
					trackedSunIndex = 0
					manualTracking = False
					launchUT = 16773352.076302484
					stagingEnabled = True
					timeEfficCurve
					{
						key = 0 1 0 0
					}
					EVENTS
					{
					}
					ACTIONS
					{
					}
					UPGRADESAPPLIED
					{
					}
				}

And for comparison, here is the same module from a "broken" solar panel:

							MODULE
							{
								name = SolarPanelFixer
								isEnabled = False
								editorEnabled = True
								nominalRate = 10
								persistentFactor = 1
								state = Static
								trackedSunIndex = 0
								manualTracking = False
								launchUT = -1
								stagingEnabled = True
								timeEfficCurve
								{
								}
								EVENTS
								{
								}
								ACTIONS
								{
								}
								UPGRADESAPPLIED
								{
								}
							}

We can see that compared to the working panel, the "broken" panel:
- has "isEnabled = False", which likely explains the lack of background processing
- has a nominalRate of 10, which is apparently a fallback value; it means that it did not have its proper output computed and put in
- has "persistentFactor = 1" - I have no idea what this means or does
- has no launchUT set at all
- has no timeEfficCurve set at all

This tells my layman self that for whatever reason, the panel wasn't initialized the same way at vessel launch as the other ones. No idea why. Or why it started happening consistently the past two days and not before. I didn't add or remove any mods during that time...

 

Edited September 26 by Streetwind

[theJesuit]

57 minutes ago, Streetwind said:

We can see that compared to the working panel, the "broken" panel:
- has "isEnabled = False", which likely explains the lack of background processing
- has a nominalRate of 10, which is apparently a fallback value; it means that it did not have its proper output computed and put in
- has "persistentFactor = 1" - I have no idea what this means or does
- has no launchUT set at all
- has no timeEfficCurve set at all

This tells my layman self that for whatever reason, the panel wasn't initialized the same way at vessel launch as the other ones. No idea why. Or why it started happening consistently the past two days and not before. I didn't add or remove any mods during that time...

I agree. that is very strange.  This is the only example of this problem and what happens if you relaunch a fresh version of the craft?

Not sure what i can do about this tbh.  Hoepfully a oneoff?

[Streetwind]

It already happened to at least three craft that I launched yesterday, but I will play some more and report back.

Edited September 26 by Streetwind

[Streetwind]

Provisional results:

• Setting "isEnabled = True" and "nominalOutput = 0.35" in the save file is enough to "fix" a "broken" solar panel. I managed to revive my otherwise useless second generation commsat that way - it now manages to stay active in the background.
• A new commsat came off my KCT production queue and was rolled out to the launchpad. Result: all four panels broken. It was sent back to the VAB.
• A large crewed Mun lander which I had finished constructing yesterday finished its rollout to the pad. Result: all four panels broken. It was sent back to the VAB.
• The new commsat, upon its return to the VAB, had its panels pulled off, and was reconstructed that way. Then it was edited a second time, placing four fresh new panels on it.
• Upon finishing construction and rollout, it greeted me on the pad with four perfectly healthy and working solar panels.

Provisional diagnosis:

• All panels currently on vessels in my construction queue are likely to be busted.
• I can fix this by removing them and pulling fresh panels from the part selector.
• There's a possibility that ScrapYard might have been at fault. I removed it today since (a) it was a prime suspect because it lets me put parts on vessels which are not "fresh" from the part selector, but rather from the mod's own internal inventory, which works in mysterious and weird ways; and (b) because I was planning to remove it eventually anyway, as it was acting very glitchy and unreliable around the various part switching features used by multiple mods in my pack, so I figured I might as well do it now. And, lo and behold, using panels not from the ScrapYard inventory appears to work...

 

I've only examined less than a handful of vessels yet, so this is far from conclusive, but it is a trend.

 

Edited September 26 by Streetwind

[theJesuit]

 

1 hour ago, Streetwind said:

 

I've only examined less than a handful of vessels yet, so this is far from conclusive, but it is a trend.

I think we you have established the culprit!  Legend!  Can you send the logs and things to the scrapyard thread by @zer0Kerbal. 

[Streetwind]

I don't really have logs...  But I did post the info in the Kerbalism and ScrapYard threads, for other people to find. Hopefully it will help someone.

In the meantime, sorry for hijacking your thread for a topic that doesn't even involve your config. But it's your fault for giving me nothing to write about! It all just works!

So far, the only actual issue with the Modular Science config that I've noticed continues to be the one or two instances of stock experiment modules not being removed from certain modded parts. (And the missing geiger counter, but you noticed that, not me.)

 

Edited September 27 by Streetwind

[theJesuit]

9 hours ago, Streetwind said:

I don't really have logs...  But I did post the info in the Kerbalism and ScrapYard threads, for other people to find. Hopefully it will help someone.

In the meantime, sorry for hijacking your thread for a topic that doesn't even involve your config. But it's your fault for giving me nothing to write about! It all just works!

Well, I'm glad we identified the issue - it wasn't hijacking the thread, it MAY have been this specific kerbalism profile. 

 

9 hours ago, Streetwind said:

So far, the only actual issue with the Modular Science config that I've noticed continues to be the one or two instances of stock experiment modules not being removed from certain modded parts. (And the missing geiger counter, but you noticed that, not me.)

Which stock experiment modules aren't removed? - I can fix that!

However the deployable breaking ground experiments are removed, nor the fancy extra EVA one with the custom animations because the kerbalism devs couldn't work out a good way of running them.  It would have required a rewrite of too much code for the volunteers of the day.

 

[Streetwind]

57 minutes ago, theJesuit said:

Which stock experiment modules aren't removed? - I can fix that!

Off the top of my head, the SDV-6 'Delphi' from SSPX has an "Observe Local Space" experiment using the stock science module.

And I'd swear there was at least one more, maybe two, that I encountered while sorting parts into the tech tree before starting the playthrough... but I can't seem to find them right now. Maybe I will encounter them again once I get a little bit further in playing.

[Streetwind]

Okay, found another potential issue, again not sure if this is your config or Kerbalism in general -

I'm now starting to get to the point where I can do long-term habitation science, but the FLOAT experiment reports that the crew has no volume to work with. As in, zero volume, not just 'not enough'. I'm using a 'Dawn' habitation module from SSPX, which is a 5-seat, 1.875m dedicatd habitation part that's currently staffed with 4 Kerbals.

My assumption is that Kerbalism assigns crewed parts a 'volume' stat. Is that just not done for the SSPX parts because they're from a different mod? Or is this a function of something this config turns off, like the other life support features?

 

Edited September 30 by Streetwind

[theJesuit]

49 minutes ago, Streetwind said:

Okay, found another potential issue, again not sure if this is your config or Kerbalism in general -

I'm now starting to get to the point where I can do long-term habitation science, but the FLOAT experiment reports that the crew has no volume to work with. As in, zero volume, not just 'not enough'. I'm using a 'Dawn' habitation module from SSPX, which is a 5-seat, 1.875m dedicatd habitation part that's currently staffed with 4 Kerbals.

My assumption is that Kerbalism assigns crewed parts a 'volume' stat. Is that just not done for the SSPX parts because they're from a different mod? Or is this a function of something this config turns off, like the other life support features?

 

It should assign a volume stat but doesn't because I ripped that all out not realising that it was needed for Science! I'll need to reinstate it.  That is a problem for next week as I'm away from my PC.

[Streetwind]

Alright, no need to hurry I found a file where the volume requirements are set for the crew experiments - I'm considering to just unceremoniously remove those so I don't need to wait for an update.

...Unless of course I can change the volume application thing myself. I did not find a patch that deals with the internal volume of parts - at least not when searching for the keyword 'volume'. Must be called something else. I don't suppose you can remember off the top of your head where that is and/or what it's called?

[theJesuit]

6 hours ago, Streetwind said:

Unless of course I can change the volume application thing myself. I

I suspect it might be adding a Habitat module.  I can't remember if I took that out.  In vanilla kerbalism this is in the System folder

[Streetwind]

The habitat config only modifies the amount of available EC... if there's a volume module to be added there, it's been completely removed, and I don't know how it would look like. So I went with removing the volume requirements on the experiments for the time being.

- - - - - - - - - - - - - - - -

Another awkward bit that could use improvement are the fuel cells, or their config in /profiles/modularscience.cfg.

(1) The description of the two modes both mention that they are consuming oxygen, and are producing water (and in one case nitrogen) as byproducts. Neither oxygen nor water nor nitrogen exists as a resource, at least not when using Community Resource Pack as my resources base (which I need because I am running USI+Nertea mods). And I have a feeling that the H2 that it requests also doesn't exist...
(2) ...because the H2+O2 fuel cell doesn't actually work. Even when providing stock oxidizer and LH2 from CRP on the vessel, this fuel cell mode does nothing.
(3) The monoprop mode, meanwhile, does work. Even though it has no oxygen to consume. It does not substitue oxidizer - it simple doesn't require any secondary input and produces no outputs other than EC. Which is good, it's what I need it to be like! But then its description probably shouldn't mention needing resources that don't exist.
(4) The monoprop mode is ridiculously powerful. Even on the basic fuel cell, it chews through something like 1 unit of monoprop per second, and produces a two-digit amount of EC/s. Not sure if intended. I only have the LH2+oxidizer mode patched in by CryoEngines to compare, which is a very sedate process that's meant to run continuously in the background as the mission proceeds, whereas this monoprop mode is more like "click this button for a quick on-demand battery refill".
(5) That the monoprop mode gets added as an upgrade through the tech tree feels pointless. The upgrade comes in exactly the same tech node as the first of the fuel cells itself. Therefore there is never a world in which you can use a fuel cell that doesn't have this upgrade. So why not simplify things, and remove the tech requirement from the monoprop mode entirely, instead just having it be part of the base functionality?
(6) Should their config maybe be moved out of that file and into the /system/sciencerework/ subfolder where all the other configs are?

I understand that much of this will depend on the user's exact setup - for example, maybe the monoprop upgrade just happens to end up in the same tech node as the fuel cell itself when using Community Tech Tree, but gets split up when using a different tech tree, and makes more sense then? And ditto for the resources. But I thought I'd provide this feedback anyway, and let you decide what to do with it. Perhaps the patches can be tweaked to only fire in installs where they make sense.

 

Edited October 1 by Streetwind

[theJesuit]

Ah.  I thought i had nerfed the Feul Cells.  They should be stock equivalents, as this is a Science Only mod.  The only reason for a profile is for seemless background processing.  Hence i thought i had taken away the O2 amd other stuff.

So no more MP feul cell in the next update.

 

[Streetwind]

I dunno, I'd leave the monoprop fuel cell in place. It runs fine without secondary resources and is actually quite useful in the earlygame, when you might have a pod with a few units of monoprop onboard but don't have solar panels unlocked yet. All it needs is an adjustment of the descriptive text and and adjustment of the processing rate. And those numbers are right there in the config.

The H2+O2 fuel cell, that one can be removed. Or replaced with a LF+Oxidizer one that mirrors stock behavior, maybe.

Hmm, I wonder if the "capacity = 5" bit is somehow involved in the unexpectedly huge output...

EDIT: Yeah, confirmed. The config has the monoprop fuel cell set at consuming 0.02/s and outputting 2.4 EC/s, but because the ProcessController module is then specified with "capacity = 5", those numbers get multiplied, and it ends up as 0.1/s, 12 EC/s ingame. So there's a quick and easy fix for the unexpected overperformance - just set it to a capacity of 1 (and 6 for the array).

 

Edited October 1 by Streetwind

[Streetwind]

And now to return to the reason I initially started posting in this thread... I think I just found the first real incompatibility between Kerbalism and USI LS/MKS. Unfortunately it's a big one, and probably not one you can do anything about...

I've seen it written in the Kerbalism documentation that if the mod detects modules from other mods that it doesn't like, it will limit its max warp to x1000. Up until now, I've had no issues like that - I could always warp as fast as I wanted.

But I'm running FLOAT in multiple vessels now - effectively temporary stations that have life support for 50-ish days. Didn't have docking ports yet when those were built and launched. And at some point, it became clear to me that I was just not getting any progress on the experiment. With multiple habitats working in parallel, I should get multiple days worth of progress for each day passing, but even after time warping for multiple weeks, the experiment timer didn't move.

Some testing and sleuthing later, it seems that when Kerbalism says that it "limits max time warp to x1000", that doesn't actually mean the player cannot timewarp any faster. Rather, it simply means that Kerbalism stops working entirely at warp speeds higher than x1000. The complete background simulation just switches off. EC gain and use, whether the vessel is shadowed or not, data transmission, and yes, even research progress - nothing works anymore.

Previously, I think Kerbalism was okay with high timewarp levels on simple vessels. I launched multiple SITE missions that completed all their biome scans just fine, and I did get warnings about EC running out on occasion even when sitting at the space center on high timewarp levels initiated by Kerbal Construction Time.

But these newer FLOAT experiment vessels, they run active habitation modules from USI LS/MKS to allow the crew of four the 45+ days habitation time I need them to have. (Although Kerbalism obviously doesn't care if Kerbals become tourists due to running out of USI life support - I play like it matters anyway.) And it seems like the mere presence of it causes Kerbalism to go on strike at high timewarp speeds. Even turning off the module doesn't help.

Which leaves the question - does the entirety of the simulation just quit? Or are only the vessels with the objectionable modules affected? I don't know, and I'm not sure how I would set up a reliable test.

But if it does pause the simulation for all vessels... ugh. If I wanted to set up colonies with long-term habitation and all that jazz, I would be limited to a maximum time warp of x1000 for the entire rest of the playthrough. That's kinda harsh to be honest. It's manageable now while I'm dealing with Kerbin and its moons, but travel times to Jool and beyond will be ridiculous. I could timewarp faster if I don't have any long-term experiments running and don't care about "cheating" background EC use and such, but that still doesn't feel good.

 

Edited Thursday at 07:50 AM by Streetwind

[theJesuit]

@Streetwind that's rough and it could be on the experiments that reqire kerbals specifically that have this issue.

Looking on Github at FLOAT in ScienceRework/Tweakables,

requirements = CrewMin:4,VolumePerCrewMin:25,OrbitMaxEccentricity:0.02,OrbitMaxInclination:0.2

The Volume would be an issue unless you removed it.  Some experiments MAY care what type kerbal you have, but not in this case. 

So maybe the experiment with MKS isn't showing favourable results? 

[Streetwind]

Yeah, I removed all crew volume requirements in order to get these (and others like it in the future) to run.

I just looked up the reference that I mentioned remembering, and it's not quite what I thought. Apparently it is certain resource converters that are supposed to impose the x1000 timewarp limit, because they might produce resources that Kerbalism is also interacting with, thereby interfering with the calculations.

The spacecraft that have the issue in my save do not have any resource converters. So whatever the problem is, it's not this issue directly. But it must be something that something on the vessel is doing...

I can reproduce the issue reliably. I've also determined that if I am actively piloting one of the affected spacecraft, that one will happily continue to run the experiment even at higher timewarp levels, while the other two will not - this confirms that it is something to do with background processing specifically, not with the experiment itself.

EDIT: confirmed that a new craft running the FLIGHT experiment, another from the habitat series, has the same issue.

 

Edited Thursday at 12:26 PM by Streetwind