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?