Vaskritaya

Alright, I think I've figured out the order of operations between RRSquad and Cryotanks that's causing issues. 1. FOR RationalResourcesSquad, RRSquad's RR_SquadTanks.cfg patches parts from specific manufacturers, deleting the RESOURCE nodes and replacing them with b9partswitch subtypes. The comment suggests it happens "without CryoTanks" but there is no CryoTanks check in the conditions. 2. FOR zzz_CryoTanks, CryoTanksFuelSwitcher.cfg looks for any parts with certain RESOURCE nodes, deleting the nodes and replacing them with b9 subtypes. Because of the earlier step, it finds nearly nothing, but does apply to parts like the MEM because RRSquad doesn't patch parts made by Sean's Cannery. This means basically no parts get the boiloff module. 3. AFTER zzz_CryoTanks, RRCompanion's TankTypes.cfg patches parts from specific manufacturers that have a b9partswitch with an id of "fuelSwitch", like CryoTanks adds. Presumably this only affects things from step 2. In the end, it mostly works: Parts have the range of fuels you'd expect them to, but basically nothing gets the boiloff mechanics from cryotanks despite the comments seeming to suggest that cryotanks should have been taking priority. I suspect, but have not confirmed, that checking for !CryoTanks in the step 1 patches would fix this.

Re CryoTanks patching: Quickly checked using a ckan instance and it seems that its a problem between b9partswitch and cryotanks, RR seems uninvolved. Will look into reporting that somewhere else. Ignore this, I'm dumb. I think I know what the problem is, I'll get to working out the specifics tomorrow.

Wanted to mention that the tanktype definitions for lh2/hydralox in RationalResources/CRP/zTankTypes.cfg are wildly out of line compared with the cryotanks mod, which makes the two mods stack up pretty questionably. This is especially strange because the ratios for methane and methalox in the same file are the same as cryotanks'. Either way, you can get significantly more lh2 per volume on tanks using the RR subtype instead of the cryotanks subtype. Not sure if this is an oversight or a creative decision, so I decided to bring it up here. Additionally, much more subjectively: I feel like the new pill tanks might have a bit too much internal volume (and maybe mass?) for their size, but that's just me. The costs are also a bit strange for the new parts but I might submit a PR for that if you don't get around to it first since it's less concrete and easier to eyeball. As a final note: I have a small hunch RationalResourcesSquad and CryoTanks weren't playing together like they should, but it's very hard to say since I'm using a pretty extensive modlist. CT wasn't applying its patches to stock tanks, despite comments in RRSquad suggesting it should have at some point. Decent odds this isn't a problem with RR specifically, but it's something you could investigate if you're bored one day and have literally nothing else to do.

Hi, love this mod so far. Just wanted to report an issue that was easy to fix on my end. Some unmanned experiments were not properly being added to the relevant techs. In KerbalismSimplex/System/ScienceRework/Tweakables/StockGroups-Unmanned.cfg, RITE, NITE and FITE are assigned to techs "Stability" and "Electrics". However, the techs' actual ids in vanilla and ctt are "stability" and "electrics", lowercase. replacing the uppercase characters with lowercase characters fixed this error, and I can now use the experiments on probes. I use Linux, so maybe its linux-specific since linux is more particular about case sensitivity. Simplex kerbalism was installed using ckan, if it matters.

Regarding my previous bug report, it seems that the bug also occurs the other way around: a background vessel not consuming snacks, while the loaded vessel operates as normal. I don't have the energy to move around all my mods, reinstall the game and try reproducing this particular variant, since I already isolated the bug to snacks in my previous report, but if it helps, I encountered this variation when launching a new mission to rescue a stranded kerbal orbiting the moon. After launching the new vessel, the stranded vessel stopped consuming snacks, while the new vessel (and currently loaded one) performed nominally. I have yet to see what happens with three or more vessels, but I will provide more information if anything new comes to light. I truly hope these problems are fixed, I spent a long time searching for alternative life support mods and decided I'd prefer Snacks to the rest even if it wasn't working properly. Edit: Big news! I ended up performing some more tests with just Snacks, and they were legitimately fascinating. I made several simple vessels of landing cans, radial snack tins, and rtgs, and zipped them up into kerbin orbits using the cheat menu. Each time I added a vessel, I observed the effects in the snacks menu. What did I see? The bug seems dependent on whether the number of simulated vessels is even or odd. When I had one, three, five, or seven simulated vessels, every vessel performed nominally. When I had two, four, or six, exactly half of the vessels failed to consume snacks during mealtime. There seemed to be a pattern, too: I had numbered the vessels in their names, and I noticed by the time of testing 6 that every other vessel in the list was failing to eat, the ones I named One, Three, and Five. @Angel-125 Assuming this isn't some esoteric quirk of my particular setup and is, in fact, a bug in the mod in general, I'd be incredibly interested in hearing the technical explanation behind it if you end up working it out. This strikes me as the kind of bug thats fun to talk about with nerds, since the causes are so bizarre. As an unrelated side note, I observed that every time I opened the Snacks menu in a new scene, it exerted a permanent toll on the CPU usage of the game until closing and restarting it. Not an enormous issue since it only becomes a problem after opening it many times, but it certainly isn't great.

Hello, I'm a fan of this mod. However, I've found a reproducible bug in which the currently active vessel does not consume snacks. While I first noticed the bug in a modded career save, the testing was done on a clean install with only the stock expansions, this mod, and its included dependency. System Information I am on 64-bit Windows 10, KSP version 1.12.3.3173, Making History 1.12.1, and Breaking Ground 1.7.1. Snacks version is 1.27.5 (bug encountered on .4, and seemed reproducible on .3 as well) Describing the Bug When the glitch is encountered, the current active vessel does not consume snacks. Vessels being simulated in the background appear to consume snacks properly. The glitch seems related to the number of vessels: While I tested it using the stock Acapello for the convenience of launching two command parts for the price of a single rocket, the glitch also occurred with single-command pod rockets in my career save, which has a space station. Steps to Reproduce Add Snacks to a clean, unmodified version of the game. Create a new sandbox save with the default settings. Launch the stock Acapello, moving Bob or Bill to the MEM for later. Get the Acapello into a stable orbit. Optionally, with a maximum of x1000 speed timewarp, orbit for a bit. The kerbals will eat one snack each at the appropriate time, about 2 hours in. Stage the Acapello until it is separated into the orbiter stage and lander stage. Burn slightly so the vessels separate over time. Set timewarp to x1000. Note that the active vessel (the orbiter) is not consuming snacks, while the inactive vessel (the lander) is consuming snacks. Switch over to the lander stage, and do the same thing. Note the lander is now no longer consuming snacks, while the orbiter is consuming snacks. Additional Information While I didn't bother testing this too much, it seemed that setting an extremely high timewarp could allow the active vessel to consume snacks during that timewarp. In my modded career save, it even continued to consume snacks afterwards, but this came with the simulation of my space station behaving strangely. Timewarp instability being what it is, I didn't feel it was worth trying to reproduce anything at those speeds, since it's already assumed to be somewhat unsafe. Screenshots and Log An imgur album of relevant images with captions can be found here. The transcript of my log, which consists of a single session since a clean install, is provided here. A large amount of it seems to be routine processes performed on first launch, so I apologize for that. The actual gameplay begins fairly far into the transcript. Edit: Apologies for the problems, Vanamonde! And thank you for the welcome.