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.