Kielm

Hi! Range upgrades (possibly others?) are not being restored when a craft is reloaded. Worse, they're being reverted when a rover is loaded. Upgrade a Science Rover - save file shows e.g. distance upgrade correctly Back to KSC Back to rover Before even opening the UI - upgrades reverted in save file. UI shows the same - upgrades have been reverted. This Rover was stored in a 'Hangar' prior to launch, if that would make any difference? [ERR 19:19:29.774] Exception loading ScenarioModule RoverScienceScenario: System.NullReferenceException: Object reference not set to an instance of an object at RoverScience.RoverScienceScenario.OnLoad (ConfigNode node) [0x0015b] in <b871d4a845ea49fe87482229167c673b>:0 at ScenarioModule.Load (ConfigNode node) [0x0000e] in <4b449f2841f84227adfaad3149c8fdba>:0 at ScenarioRunner.AddModule (ConfigNode node) [0x0005e] in <4b449f2841f84227adfaad3149c8fdba>:0 Link to zipped logs & save game

Hi, I just wanted to check my assumptions based on what I've found searching through this thread: Scatterer disables the in-game Antialiasing, so deselecting the in-game antialiasing is preferred to avoid artefacts. Or at least, scatterer will disable/override it (I assume permanently) when changing scenes - is that right? Should I turn the stock AA off? Scatterer defaults to TAA as it's preferred anti-aliasing I play in 2K so aliased edges aren't a huge problem, but I still prefer some minimal antialiasing to smooth them out. However, I've found I'm particularly sensitive to Temporal Antialiasing and the way it can cause 'ghost images' when in motion, so tend not to use it if I have a choice. I think (assume) that scatterer implements it's own TAA so this may not be a problem, but would there be a significant performance impact in switching to scatterer's SMAA implementation instead of it's TAA? Or should I just disable scatterer's antialiasing entirely and use in-game (stock) antialising instead?

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: Ryzen 5800x | GPU: Rx6700xt | RAM: 32GB Using Ion engine ("Dawn"). Attempting an ejection burn out of Kerbin's SOI: Time Warp to before periapsis Stop time warp Throttle up Engage time warp Disengage time warp Set throttle to zero. Repeat steps 1-6 enough times and after several (5-6) orbits, thrust will no longer be produced at >1 time warp. Curiously, throttling down allows time warp to be engaged again. Each subsequent orbit requires a lower and lower thrust in order to engage time warp. Saving & reloading does not rectify the issue. No mods. The craft is named Duna Probe I-14. Included Attachments: quicksave_1.json Save2023-12-30.json .ipsImage { width: 900px !important; }

Is it normal to have Karborundum availability increase with distance from the sun? I wasn't sure what was going on with my distribution so I ran a quick test, only thing I can think of which might cause this is Kopernicus but I don't have any other stars in the game. Is this just a chance based thing or something wrong?

I found myself overwhelmed with the choices when it came to beamed power, and struggling to figure out what antenna / wavelength etc to use for varying scenarios, so I threw together a quick spreadsheet to help with the calculations. Should be pretty self-explanatory, you can enter an SOI from Kerbin (e.g. Duna) or manually enter a distance and it'll show the spot sizes at various wavelengths. Enter your antenna aperture size and you can work out what size antenna you need at various wavelengths / distances. Anyone is free to make a copy and use it yourself. Find it here (google sheets link)

I found myself overwhelmed with the choices when it came to beamed power, and struggling to figure out what antenna / wavelength etc to use for varying scenarios, so I threw together a quick spreadsheet to help with the calculations. Should be pretty self-explanatory, you can enter an SOI from Kerbin (e.g. Duna) or manually enter a distance and it'll show the spot sizes at various wavelengths. Enter your antenna aperture size and you can work out what size antenna you need at various wavelengths / distances. Anyone is free to make a copy and use it yourself. Find it here (google sheets link)

Glad you found it. Never even occurred to me to ask!

Hmmm. You're using a laptop with integrated graphics, which has 8GB RAM shared between the graphics card and the rest of the system. You're automatically under the recommended minimum 8GB for this mod, so I'd say that's likely the root cause. Win10 will happily use a couple of gig on it's own, leaving maybe 6GB for KSP - and that's before the integrated graphics eats it's share. I checked, and the integrated graphics on your Intel® Core™ i5-1035G1 Processor laptop says it supports up to DX12 so it's probably not a driver issue (though, you could try updating your integrated graphics drivers to be sure). My money is on your system running out of RAM/VRAM. If you post a link to the crash dumps at C:\Users\itson\AppData\Local\Temp\Squad\Kerbal Space Program\Crashes I can run it through a debugger which may shed a little light (or not), but my money would be on either graphics drivers or insufficient RAM/VRAM.

It's been working fine for me in 1.12.5; I've built kits, launched, docked and constructed them in orbit with no problems.

Waaaaay back when (six years ago), I wrote in some "compatibility" for IFS into this mod but the PR never made it in. I say "compatibility" as it was definitely not in the spirit of the word -- it grabbed a reference to the IFS module (public fields) directly from the part that an upgrade was being attempted on at runtime and overwrote them. I'm not sure if "overwriting module fields from other mods at runtime" qualifies as compatibility but hey ho. I remember testing it out briefly without any noticeable issues, but it was mostly a 'proof of concept' piece, and I have no idea how stable or relevant it would be now. Many of the fields in IFS aren't even the same any more. However, should anyone want to take a look and update the code for KSP 1.12.x to try it out, feel free. https://github.com/mmoench/KRnD/commit/d337abdd6cdb4c3f36789683515091bbad2bc2ad https://github.com/MrKiel/KRnD

That is perfect, thank you! I'd completely forgotten about MKIV Spaceplanes too, might just slip that in while I'm there

I'm attempting to build a station to assemble DIY kits but I can't seem to find any containers to transport MaterialKits. Is anyone using a container for MaterialKits that isn't USI Core? I'd prefer not to install all of the reactors, unnecessary parts, fuel switches extra bells and whistles just for the sake of moving some materialkits around.

Put a Universal Storage II Materials Bay (wedge) on a craft. Launch it, and attempt to use sciencealert to gather the science from it (deploying or not beforehand makes no difference) Whether the bay has been deployed or not, the science experiment will show as normal, and the option to retain/transmit it will appear. If you opt to keep the experiment results, the bay will lose the data and become inoperable.

Workaround doesn't work - even opening the bay doors first and using sciencealert to run the experiment breaks it. How annoying

Update to this issue in the thread above. Auto-science mods (sciencealert, [x] science, potentially others) are allowing science experiments to be run in modules that should be deployed first. The player can't normally do this so the part is entering a state it shouldn't; it becomes 'full' of science, shows as deployed/locked, and no further experiments are run. Unfortunately, as it's not deployed when this happens, it can't be emptied either, and the experiment isn't stored as well (it's lost/destroyed). Workaround is to deploy the science parts manually before running any science. Never mind - I wouldn't use sciencealert/[x]science for these parts for now.

Update on this Universal Storage II issue: It's caused by the science experiments not being 'deployed' prior to an experiment being run. Normally the player cannot run an experiment without deploying the module first but ScienceAlert inadvertently bypasses this I was wondering why I hadn't noticed before, so I checked the science archive, which just shows no data recovered for the affected experiments. So the experiment is recorded in the archive, but the science data on the craft is immediately destroyed and the experiment is locked (USII thinks it's full, and locks the part until it's emptied, but it can't be deployed or interacted with - it's entering a state it shouldn't be in). Workaround is to manually deploy everything before doing any science. Nope, even that doesn't work Hope this helps.

Hi, Small(ish) issue on Universal Storage II science parts, which seem to enter an unusable state (and loss of the science data) when activated by this (or another) auto-science mod, and then EVA collection of data is attempted. I'm not 100% on the conditions, it doesn't seem to happen with recovered parts, at least not that I've seen yet. Likely caused by USII's custom science module implementation as sciencealert works fine elsewhere. I've posted logs here Just a heads up in case there's anything that could be done in differently in sciencealert to avoid this scenario occurring in USII?

Update: I've done some bug hunting and it looks like universal storage II science parts can enter a state where the science part is empty (no experiments) it is "deployed" i.e. used, full, as far as USII is concerned, and therefore inoperable Any data that was stored internally is discarded/lost KSP Log File Persistent.sfs Opening the attached persistent.sfs and searching for "USMatBayWedge" will show the first affected part. It seems to be related to manually removing data from a science part while on EVA. Actions from auto-science mods (science alert, [x] science) may be creating conditions for this to occur. I'll have to test again tomorrow, but sciencealert (for example) does not set the module to this state, only USII does - the source of the issue is likely USII's custom implementation of ModuleScienceExperiment (USAdvancedScience).

I also just had this problem. A scientist on EVA was not able to empty the module. I'm using science alert, I'll try manual activation and see if that has the same problem.

I used the systems from the previous version, which I realise are not supported or intended for 1.4.2 but hey - why not, I was just testing it out. Would that cause the high RAM usage or is that likely to happen if I use all systems on the previous version as well? Reading around, I guess the answer to my original question is "pick whichever systems you want", as long as they're supported for the version you're using. I was just hoping to get some recommendations, that's all

Not at all! It worked fine with all the systems and expansions installed, but using 24gig before I'd even installed any other mods. I'm just not sure which systems to pick to keep the ram usage reasonable and allow some headroom for other mods.

I installed 1.4.2 with all the available systems and expansions and KSP used 24Gb of RAM. I'm assuming I'm not supposed to do that, so should I just stick with the systems (not expansions)? ... should I be using 1.3 instead?

I've attached the full player.log to the issue in case it helps. Let me know if you could use anything else.

Negative, 1.11.2

Constellation 2021.03.12.01 PRE-RELEASE oops and another Disclaimer: I don't know if these are actually causing crashes, but they're adjacent to the crash message in player.log. EDIT: Github Issue