Professor K

I think you hit the proverbial Kerbal on the head, or at least partially. A search for SpaceDust in mods other than yours turned up a SpaceDust folder in the Parts folder of "Cacteye 2 Refocused" that included a set of localization files from a 2022 version of SpaceDust. The author appears to have been attempting to integrate the functions of your mod's telescopes into that mod while removing yours from the parts list. No stray DLLs though. Removing the CactEye mod from the sandbox setup seems to have fixed the unit display issue. Unfortunately, removing CactEye would break my ongoing game, so I need to figure out what exactly is happening and try to fix it. At first perusal I think simply removing the localizations from the CactEye spacedust folder will do the trick, there doesn't seem to be anything in them that's not in the latest "real" one. These and the original screenshots are all from orbit around Kerbin with force Discover and Identify turned on in the SpaceDust config. That was me experimenting with adding ring shaped bands in order to learn how to add them for an additional planet pack I have. I was adding them to Kerbin to make testing easy. I do have an odd issue with that as well, although I was hoping that resolving my original issue would resolve it. It has not. Without my additional bands, specifically the OX one, I see an atmospheric band of OX, as shown in the first image above. With my band in place, the Atmospheric band disappears and I see two identical exospheric bands of OX as shown below. Turning on display of either of the two duplicates shows the same exosphereic band. // Defines Oxidizer definitions for Kerbin exosphere // KERBIN // So many fuel tanks have been vented and otherwise lost around Kerbin that it has low concentrations of gasified oxidizer to collect // ============= SPACEDUST_RESOURCE:NEEDS[SpaceDust] { resourceName = Oxidizer body = Kerbin RESOURCEBAND { name = kerbinOrbit title = #LOC_SpaceDust_Band_Orbit // Discoverability Data // -------------- alwaysDiscovered = true alwaysIdentified = true bandType = Exosphere // Maximum and minimum abundances (variation is by game seed) // In t/m^3 minAbundance = 0.0000000000276 maxAbundance = 0.0000000000306 // Scale abundances by air density useAirDensity = false // Distribution Data // -------------- // Distribution model to use, can be Uniform or Spherical distributionType = Spherical // These parameters are specific to the Spherical model // ------- // Altitudes are in km from sea level // Maximum altitude for a distribution altUpperBound = 650000 // minimum altitude for a distribution altLowerBound = 80000 // peak of a distribution altPeak = 300000 // maximum variation of these altitudes (variation is by game seed) altVariability = 10 // Falloff for altitude, can be Linear or None altFalloffType = Linear // lats in degrees // Maximum latitude for a distribution latUpperBound = 10 // Minimum latitude for a distribution latLowerBound = -10 // peak of a distribution latPeak = 0 // maximum variation of these latitudes (variation is by game seed) latVariability = 1 // Falloff for latitude, can be Linear or None latFalloffType = Linear } } -K

Some additional troubleshooting: Even after the re-install, the harvester itself is showing all the resources in u/s. The scanners and the map screen info are in u/m3. I set up an atmospheric processor from the base SpaceDust parts and it also listed the resources in u/s, although both the OX and Argon present did harvest as expected. I found this line in the English localization, which looks like it should be the UI line used for the Resource PAW lines. Possibly the mod's code is not reading it and dropping back to an internal default? #LOC_SpaceDust_ModuleSpaceDustHarvester_Field_Scoop_Resource = <b><<1>></b>: <<2>> t/s -K

Thanks for the quick reply. The listed versions came from the version files in each folder, but I just deleted and reinstalled FFT with all it's included dependencies from a freshly downloaded copy from Spacedock and the PAW description still says "u/s". I even launched a new copy of the ship in a sandbox to double check. The only thing I noticed when comparing what I had to the new copy was that the version of SpaceDust I originally had was the standalone one from SpaceDock (which was labeled 0.5.4, the same as the one in the FFT archive) but the file dates on it were 10/9, where the dates on the SpaceDust files in the FFT archive are 10/18. It doesn't seem to have made a difference though. The 0.5.4 version from SpaceDock was the first version of SpaceDust I ever installed, so I don't believe anything could be left over from an older version. -K

I've seen a number of recent posts from folks having trouble gathering liquid hydrogen but no solutions as yet so I thought I'd post my issue with it as well now that the forum is back up. Using: KSP 1.12.5 FFT 1.4.2.0 SpaceDust 0.54.0 SystemHeat 0.7.2.0 Cryotanks 1.6.6.0 HeatControl 0.6.2.0 Here's what I see in flight with the PK-EXP "Bussard" Particle Scoop (fft-exosphere-scoop-1) If I'm interpreting the numbers correctly, the scoop is seeing 4.25E-13 u/s LqdHydrogen and the minimum for collection is 1E-20 u/s (as per the part config). Unless I'm misremembering how to convert scientific notation to real numbers, that's 0.000000000000425 u/s LqdHydrogen, considerably more than the 0.00000000000000000001 u/s minimum for needed for collection. The info box seems to be saying that the harvester is working, but nothing is being added to the half empty tanks regardless of how long I let it run. I've tried the scoop with other gasses and it seems to work with them. Am I missing something obvious here? -K

Is there trick to getting the inflatable flotation devices to work? I'm not getting any deployment options when using them, regardless of where the craft is. Specifically the "KM Inflatable" and "KM Inflatable, Large". -K

That seems to be the issue, VABOrganizer appears to be causing the depreciated parts to show up in the VAB, but unlike the others that have a description of "depreciated", that RTG has nothing. Edit: Found the real issue. Apparently I had a senior moment and didn't delete the old version before dropping the last update into place, leaving a bunch of old/renamed parts config files in place. -K

Small bug: In Near Future Electrical, the English localization for the PB-AS-NUK Radioisotope Generator seem to be missing. -K Quick Google Translate for anyone who wants to fix it before the official fix goes in. #LOC_NFElectrical_rtg-0625_title = PB-AS-NUK Radioisotope Generator #LOC_NFElectrical_rtg-0625_description = Utilizing a higher amount of Blutonium-238 than the PB-NUK and a more efficient power conversion system based on reverse-engineered Post-Kerbin generator technology, Ionic Symphonic engineers have refined this advanced RTG for cost-effective yet continuous power. #LOC_NFElectrical_rtg-0625_tags = active atom charge e/c elect energ generat isotope nuclear nuke power radio rtg stiring thermo volt watt nearfuture mmrtg

Is anyone else having an issue with the "self destruct" option on a staged section taking out the parent vessel as well, even though they have been decoupled and are several kilometers away? KSP: 1.12.5 TAC SD: 1.7.0.3 -K

Ah, ok, that actually makes sense. The planet pack has issues with it's height maps (landing is tricky when the altimeter gets to zero, then resets to several hundred meters while the Kerbal Engineer altimeter starts counting into negative numbers). Thanks! -K

What, exactly, does SCANsat base it's map data on? I ask because while it works normally for me on the stock planets/moon, it's not working on some extra moons done with Kopernicus (not made by me, I jut seem to one of the early downloaders of the mod pack). The scanners seem to be working and are showing "Ideal" Orbits in the sensor info, there's jut no map data showing up (Except fora single flag on one) . The mod has some texture issues and I'm trying to help the author troubleshoot but we're not sure what SCANsat is looking at to do so. Mod Pack in question: https://spacedock.info/mod/3273/ExtraKerbin Moons -K

Ran a few quick tests on the update: This seems to be working. I'm not seeing any issues with this now, it seems to be visible right up until it's obscured by the dot that the system puts over all bodies at long zooms. These are not working. Ringer has an SOI of 30km now. It's own ring is outside it's SOI I think I see the issue though. It looks like the SOI is measured from the center of the planet, so Ringer with a radius parameter of 70000 and a sphereOfInfluence parameter of 100000 = a functional SOI of 30000. I believe the sphereOfInfluence setting would need to 170000 to give a functional SOI of 100000. I'll alter the cfg file and test next time I restart the game. EDIT: Yup, that did the trick. You need to add the Radius to whatever you want the functional SOI to be. to get the number for the sphereOfInfluence parameter. I think something went wrong with this. Ringer is visible in the map view (although very bright) but in flight view it's completely black. In the screenshots below, the first is in orbit, the black area behind the craft with the faint white edge is Ringer, from the daylight side. The second shot is landed, again on the daylight side, you can see a slice of ring in the background but none of the surface. Another strange thing I've noticed is some odd behavior with altitude when landing. I'm seeing this on Niermun and Ringer, the screenshots below are from Niermun. When landing the altitude will be deceasing seemingly normally but will reach 0 (ASL or Terrain) while still several hundred meters above the surface, then will suddenly jump up several hundred meters (the gauge, not the craft itself) while the altimeter in Kerbal Flight Engineer will start counting down into the negative numbers. This makes landing somewhat tricky (and gives the MechJeb lander module absolute fits). This was occurring before the update. I was hoping the new Normals would fix it, but no such luck. I'm not certain what the game engine bases the altitude on though.

Greetings! Love this little mod, It's my first time using Kopernicus in a playthrough and something that didn't alter the stock system is exactly what I wanted. I tracked down this thread to report a few issues I had noticed, but @JcoolTheShipbuilderappears to have covered almost all of them already! The one thing Jcool didn't cover... I'm not sure if it's possible/practical to do anything about this. I'm also using Scansat for the first time in this playthrough and the low altitude scanners state an optimal orbit of Niermun for scanning as >34km , however Niermun's SOI appears to be somewhere between 33 and 34km. Is it possible to alter the SOI or is it computed by the game engine based on the body's stats? -K

The new companion checker, while a nice idea, seems to be rather over enthusiastic, if not downright aggressive. To the best of my understanding, not having a companion for a mod simply means no Tweakscale on those parts (PKMC). That's not a "show stopper", save game breaking issue in my book. I didn't have Tweakscale on those parts before and I still won't have it. That shouldn't break anything. And insisting on a companion listed as still in Beta (Multipass) is not a good idea in my opinion either. The really, REALLY annoying part was when it shut KSP down when I clicked OK though. I'd missed the line about doing so shutting KSP down and "OK" means "keep going" to me. There should be an "are you sure?" check on this. KSP take too long to load to not have a check. If this will be the way the companion checker works, can we get an option to disable it? Or at least a "Don't warn me about these mods again" option? -K

Before I open a bug report, has anyone else noticed MechJeb being added to the MicroSat twice? This is the only command group part that this seems to be happening with and if I disable the MechJeb patch that comes with this mod then new instances of the part only have one MechJeb. A check of the craft files shows two "MechJebCore" modules on the ones created before disabling the patch. The patches that come with MechJeb appear to be covering adding itself to the MicroSat, it looks to me like the separate patch is not needed. -K

Love it! -K

Very excited for the interstellar travel (when it gets added, that is!) -K

Unless you're planning on adding a lot more parts, I'd keep it as one. -K

Done. -K

Anyone else have the Soil Sample experiment nearly throw a 100 ton base off of Minimus when it extended and hit the ground? I've been looking for a setting for the animation module to stop when hitting something, but haven't found one yet. -K

I know this was an older post, but I don't see any responses and I'm having the exact same issues with the wheels. They seem to have next to no power, no slope climbing ability and a set of 4 of them burn through the 500 unit battery in less than a minute, even with no load on the platform. -K

My download of v2.1.10 seems to be missing a texture file. I'm getting the following error: [LOG 22:38:25.798] Load MU model: StationPartsExpansionRedux/Parts/Rigid/station-5/sspx-dome-cupola-5-1 [ERR 22:38:25.844] Texture 'StationPartsExpansionRedux/Parts/Rigid/station-5/sspx-internal-5-6' not found! The file is not present and I doubled checked the .MU file, it is referencing that texture. I also took a look at the github repository and I don't see the file there either. Can anyone point me to a copy of the missing texture? -K

That's pretty much how I name all of my ships. -K

I've found that a lot of things shake and drift on the runway. Does it do the same if you launch it to the launchpad?

I do not, no. -K If It helps, here's all the mods I'm running. <DIR> 000_ClickThroughBlocker <DIR> 000_Harmony <DIR> 000_KSPAPIExtensions <DIR> 001_ToolbarControl <DIR> 999_KSP-Recall <DIR> AutoAGL <DIR> AxialAerospace SimpleCargoSolutions <DIR> B9PartSwitch <DIR> BetterCrewAssignment <DIR> BetterScienceLabsContinued <DIR> BoulderCo <DIR> Chatterer <DIR> ChopShop <DIR> ChromaWorks <DIR> CommunityCategoryKit <DIR> CommunityResourcePack <DIR> DaMichel AeroRadial SphericalTanks <DIR> DefaultActionGroups <DIR> DistantObject <DIR> EasyVesselSwitch <DIR> EnvironmentalVisualEnhancements <DIR> FP_DPSoundFX <DIR> GoodspeedAerospace <DIR> GPOSpeedPump <DIR> HotBeverage FuelCells SensorModules <DIR> IndicatorLights <DIR> IndicatorLightsCommunityExtensions <DIR> Kaboom <DIR> KAS <DIR> KerbalEngineer <DIR> KerbalHacks Droptanks <DIR> Kerbaltek Hyperedit <DIR> KipEng KipDockingPorts <DIR> KIS <DIR> KSPCommunityFixes <DIR> masTerTorch KerbalDustExperiment <DIR> MechJeb2 <DIR> MiniSampleReturnCapsule <DIR> MK1CabinHatch <DIR> ModuleManagerWatchDog <DIR> NearFutureConstruction <DIR> NearFutureExploration <DIR> NearFutureProps <DIR> PapaKerballinisPizza <DIR> PlanetaryBaseInc <DIR> ReStock <DIR> SciencePancake <DIR> SolarScience <DIR> StationKeeping <DIR> StationPartsExpansionRedux <DIR> StationPartsExpansionReduxIVAs <DIR> SurfaceLights <DIR> TrackingStationEvolved <DIR> TweakScale 000_KSPe.dll 666_ModuleManagerWatchDog.dll 999_Scale_Redist.dll Delta-V Map.ksp KSPCF_UserSettings.cfg KSPModFileLocalizer.dll ModuleManager.4.2.2.dll ModuleManager.ConfigCache ModuleManager.ConfigSHA ModuleManager.Physics ModuleManager.TechTree PlanetWiki_v4.1.ksp remove_fun_part_patch.cfg

I'm sorry, but I was rather frustrated at the time (having just lost 2 hours work of getting through a tricky rescue mission) and I didn't save a copy of the log file. The errors were virtually identical to the ones @GoAHead posted though. I'm running KSP 1.12.5 with both DLCs installed, all through Steam, under Windows 10-64bit. The ship I was on had no parts altered with Tweaksacale at all. -K