Streetwind

Now that the forum is back, I can continue to report experiences: The CHILLED experiment requests "a greenhouse" be present as a requirement for running. But what actually counts as a greenhouse for this experiment, given that the rest of Kerbalism is missing in the context of this science-only config? I tried a USI-LS agroponics unit, but (perhaps unsurprisingly) this didn't do anything.

I see. I was planning to reuse the same space stations that did the FLOAT and FLIGHT experiments. They're all set up as cores of command and life support, and experiments dock to them and stay a while until they're done, then leave. Otherwise, why bother having space stations at all, if you can't use them for more than one thing? But I guess this one might have to be a dedicated spacecraft... or just pack the batteries required. I'll decide later.

Well, one thing I can see is that the stats for the two new RCS blocks make no sense. At least, the stats visible by rightclicking them in the pats list in the editor. Because I looked into the definition files, and the stats within the B9Partswitch group do seem to make sense. But each of the thruster blocks also has a separate ModuleRCSFX, presumably for the editor to be able to show something, and that one has numbers which don't reflect each part's actual performance. On the ARC-L, the editor shows the thrust and power draw of the lithium mode, but the Isp of the hydrogen mode. On the ARC-µ, the editor shows ten times the thrust it should have (equal to the ARC-L). Also, the release notes say that the ARC-µ should use "10kW" of power, and the ARC-L "100kW". Meanwhile, the editor shows 100 EC/s for the ARC-µ, and 60 EC/s for the ARC-L. Regardless of what conversion rate between EC/s and kW one uses, those numbers don't line up

Quick question of curiosity - are batteries more dense in Kerbalism than in stock? Not talking about mass, but rather volume. I'm trying to set up a CHILLED experiment, which asks for 23.1 EC/s - four times as much as the previous most-energy-hungry experiment I had access to. Now, adding four modest OX-10L solar panels easily covers that on the power generation front while the station is in sunlight. But when it comes to getting through darkness in orbit? I need around 30,000 EC storage, which with stock parts is roughly the size of the entire lab itself. (Well, stockalike parts, given that I'm using the 1.875m lab from SSPX and the 1.875m battery rings from NF Electrical.) And that's not covering the rest of the stations needs, like life support and comms - just the experiment alone. This feels off to me, in that "I'm not sure someone actually intended this" sort of way. So, how would you perform this experiment in full-on Kerbalism? Do you have much denser batteries that take up less space? Do you have access to nuclear reactors there by the time you unlock it? For me at least, using CTT, reactors are still a good ways off at this point. And fuel cells are not viable either, given this experiment needs to run for something like 140 days straight. (I'm not saying this is necessarily broken and needs a fix. The lab module can certainly launch this way. I'm just curious whether this is a side effect of using Kerbalism science outside of Kerbalism's other trappings, or whether it's meant to be this cumbersome even in the original context.)

Argh... I want to update... but I'm already in the middle of a heavily customized playthrough... choices, choices...

Thanks! But after thinking it over for a bit, I probably won't update. At this point I've made so many customizations to the config, and I've also got three space stations that are actively being used, which were built without knowing the volume calculations - and so I'm hesitant to change my currently working setup. It'll be good for other people though

@Xt007 I understand stock transmission range and signal strength, as well as how Kerbalism attenuates transmission rates when signal strength drops. In this case there is 100% signal strength along every single hop of the route. There should not be any attenuation. Additionally, when I undock the supplies barge and thereby remove the small extra antenna, the vessel's transmission rate immediately shoots up to the 12.88 kB/s limit of the relay. So this has nothing to do with distance, and everything to do with Kerbalism screwing up the combinability of stock antennas.

Oh, it's every bit about life support. Because the vessel is running an experiment outputting 7.8 kB/s, and was supposed to be doing this for two weeks. And it has life support for around three weeks. Problem is, because the antenna is running at less than half the rate of data output, the experiment gets stalled out and won't finish before the life support runs out. In the meantime, I figured out what's going on. There is a small supplies barge docked to the vessel in question. The barge is supposed to undock and deorbit itself once exhausted, hence it still has its transfer stage section. Which, since this is an uncrewed barge, includes... another antenna. A Communotron 16-S, tucked away inside a service bay, where it can't be seen and therefore was easily overlooked. I like using the 16-S this way, because it doesn't need to be extended, and I keep forgetting to extend other antennas, which has caused more than one vessel going dead just before circularizing. And despite the 16-S being uncombinable in the stock game, under Kerbalism rules it apparently can be combined with other antennas. So instead of having the vessel use its 4Gm, 25 kB/s DTS-M1 for data transmission, it instead uses that powerful antenna to boost the tiny 16-S's anemic rates. -__- So much for realism... And, since the 16-S cannot be extended, it of course cannot be turned off either... Moral of the story: only use extendable antennas for any vessel designed to dock with something that has a stronger antenna. Otherwise you as good as disable that stronger antenna just by docking to it.

A question on the topic of antennas and science transmission rates: Does bouncing the singal through a relay affect the possible transmission rate? The documentation doesn't mention any of this. It at most suggests that the data rate of the weakest relay would bottleneck the transmission rate even if stronger antennas are involved elsewhere on the path. However, in my game I get much worse results than that, and I'd like to understand the details. Example: - A vessel has a direct antenna with a 25.00 kB/s maximum transmission rate - A relay satellite has a relay antenna with a 12.88 kB/s maximum transmission rate - The vessel has a 100% link to the relay, and the relay has a 100% link directly to KSC - The vessel actually transmits at... 3.55 kB/s? But why?

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.

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.

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).

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.

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?

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?

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.

Appears to be working fine. The new icons override the questionmark icon that ResearchBodies attempts to give newly discovered bodies, but tbh I don't care May I request an "A" icon, for "asteroid"? Would be applicable to Gilly, Bop, and a number of other sub-planetoid bodies from planet packs.

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.)

I've discovered what appears to be a(nother) incompatibility between ScrapYard and Kerbalism. Kerbalism places a custom module called SolarPanelFixer on all solar panels. This module supercedes the stock solar panel module, and enables things such as background processing, and decay of solar panel performance over time. Since the module records the time of launch, I suspect that it runs custom code when a vessel is sent to the launchpad. And it seems that custom code is either not running at all, or it is broken, when using solar panels from the ScrapYard inventory. Such a panel on a vessel in flight will have "isEnabled=false" set, and a boilerplate value for power output that's completely independent of panel size (a tiny OX-STAT and a Gigantor array will both output the exact same power). Much of this is conjecture, but in my save I can reproduce the behavior reliably. Only solar panels fresh from the part selector work correctly with Kerbalism background processing. Previously used panels from the ScrapyYard inventory are broken.

This seems right up my alley. Let's see whether it breaks when thrown into a running game with ResearchBodies and several planets in various states of partial discovery

A small heads-up, since I've seen multiple people report having problems with solar panels not producing power in the background in this thread, and I encountered the same issue too: On my end I was able to track it down to using ScrapYard. Pulling solar panels fresh from the part selector was fine, but re-using panels from the ScrapYard inventory resulted in them not working properly. The reason is probably that Kerbalism's bespoke solar panel module which replaces the stock one and enables the background processing also attempts to record the time when the vessel was launched (to model solar panel decay over time, I think). That means it must run custom code when a vessel is sent to the launchpad. And it seems that that code is either not being run for the re-used panels, or the code breaks; either way, it results in an inactive module with boilerplate values. If you look up an affected vessel in your savefile, you'll be able to see that the module has "isEnabled=false" set, and likely some wrong values in other fields.

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.

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

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...

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?