TicTac

Yup, I submitted a pull request for this on Github but it seems like it hasn't been patched yet. You'll also want to double the position and scale values for the z1001amp indicator light in the same cfg file to get it to show up correctly on the full size model.

I've got KSP v1.7.3 and US2 v1.7.0.10 installed via CKAN, thanks for checking!

I asked this in the main thread, but got no response. Is the issue of wedge values not saving and the UI bugging out when you change wedge size fixed in the upcoming release? The issue w/ wedge values specifically make it tough to balance assymetric service modules, since they reset to full when the craft file is loaded. The new models look great, btw! Loving the look of the service modules.

Is this still an outstanding issue? I noticed it when using v1.7.0.10 on CKAN.

I noticed that the Indicator Lights patch for ReStock was changing the scale of the small radial battery. As nice as it is to be able to fit loads of them on a small probe, I don't think it's the intent of this mod to change the underlying models. I've submitted a Pull request on GitHub to patch this, hope you find it useful! https://github.com/KSPSnark/IndicatorLightsCommunityExtensions/pull/4

@Sir Mortimer I'm not using remote tech, just the stock comnet for what it's worth. I'm glad to hear that BG processing is ironed out in the dev build! If that error is not from Kerbalism, then I'm not entirely sure... "RPM..." makes me think it could be Persistent Rotation, but that's just a guess. My log is extremely bloated with what looks like Contract Configurator messages, so it's hard to sift through - that snippet showed up a few times and was the most relevant looking result when I searched for Kerbalism, apologies if it's not useful. [EDIT] Looking into it a bit more, it seems like RPM is Raster Prop Monitor - My mistake.

Having just run up against this problem, I was wondering if the devs are aware of it? I've noticed that many experiments take inordinate amounts of time to process in the BG, which can only be partially attributed to bandwidth and power availability. The nail in the coffin for me was running seismic scans on the moon which just would not progress if the vessel wasn't active. Kerbalism would show the vessel power correctly, but not that it had a connection to KSC, when it was in the background. Upon switching to the vessel, it immediately connected and began transmitting. This turned a couple of (optimally) 14-day scans into a 300+ day endeavor, due to legitimate power outages and these illegitimate comnet blackouts. I just checked my KSP log, there's a fair bit of these messages throughout - not sure if they're related or not.

If you've made it to orbit, the hardest part should be behind you. There are at least a few experiments that are Biome specific, and while they might not yield a ton of science it should be enough to start unlocking more and more experiments.

I'm not sure how CrowdSourcedScience as a whole works, but it seems to store it's messages in a much more organized fashion. It might be possible to look up a value from their .CFGs - they're organized by planet, then biome, then experiment type with fallback defaults in a few different places. For example, a Crew Report from Duna at high altitude would be in planets/duna/default/crewReport.cfg > "DunaInSpaceHigh = The crew is concerned that the planet is "too red". Mission Control does not believe this is a good reason to go home." A report from the ground would be in planets/duna/northernshelf/crewReport.cfg > multiple options labeled "DunaSrfLandedNorthernShelf" I don't think this is a huge priority given how science is processed in the background now, but food for thought if anyone wants to try and incorporate situation-specific messages.

I'm not sure if this fell through the cracks or not, but I didn't see an issue posted on the Kerbalism Github. @Sir Mortimer ?

I believe it's lead, somewhere in the UI it refers to shielding as (mm Pb).

@nightingale Also an issue with Kerbalism 3, the blue 'Science Transmission' popups get really spammy. Can we get an option to disable the popup altogether?

Does Kerbalism 3.0 require a new save? I have a career with Kerbalism 2.1.x that I'd like to continue with 3.0. I plan on testing it myself, but I was wondering what the official word was.

SVE adds them using EVE if I'm not mistaken.

@N70 I'm also having this issue, I've got Kerbalism v2.1.2 installed from CKAN w/ dependencies and am running KSP 1.6.1. I just checked, this will happen on a clean installation of 1.6.1 w/ Kerbalism and Community Resource Pack. It does not happen on a clean install of 1.4.5 w/ Kerbalism and CRP, though. Hope this helps

My gut tells me that it will be easier and probably simpler / less error prone to delay launching using the game time than to add resource to a craft and have it drain on the pad. My first attempt would probably be similar to KCT, where clicking launch in the VAB adds your ship to a queue and it's then able to be launched once its timer runs out. The goal for me, and from what I can tell in this thread for you guys, is to make it up to date with ksp and to strip it down to the bare essentials - ships take time to build and roll out based on their complexity (cost), and this process gets faster as the VAB and SPH are upgraded. Possibly the same system for research, at least as an option. This way there is less complexity, and hopefully it's easier to maintain. I would also try to make as many things optional as possible, so you can say disable rolling out after building, or make research instantaneous. But again, with no experience modding ksp this is a shot in the dark for me.

I would be interested in making a light KCT mod, but I don't have any experience in either modding ksp or coding with c#... So it would take me a while just to get going. I'm going to have some more free time than usual over the next couple of weeks, so I may take a stab at it. I'll update here with how things go.

Great, thanks kerbas! I'm stuck on KSP 1.4.5 until a few of my career mods get updated, but I was able to patch that change into my copy of the mod and it worked like a charm.

@Kerbas_ad_astra There's an issue with the Skipper engine where its shroud clips through the part above it in the stack, and its bell comes very close to clipping through the part below its decoupler. As far as I know, this problem is unique to the Skipper... though I might only notice it there because I use it as a 2nd-stage engine often. This screenshot a simple fuel tank > engine > decoupler setup with the Skipper on the left and Poodle on the right - the Skipper is highlighted to show the shroud clipping up through the tank. Ven Stock Revamp v1.10.0 is the only mod installed here, on KSP v1.4.5 The clipping is enough to have stages 'stick' together after decoupling, oftentimes badly enough that they can't be knocked loose without damaging the upper stage. Sorry if this has been fixed already, but I haven't seen any mention of it in commits on github.

I'm also having the bases and stations flickering issue, I posted in their thread but linuxgurugamer suggested raising the issue here. From my post there: I have a few contract packs installed, and only Bases and Stations is effected. For me, missions to launch a station will become available and then disappear within a few seconds. Clicking on the "Launch a Station" mission when none are available shows all criteria met except for "Target Not Sun". The behavior looks almost like it's still re-rolling the contracts after they appear on the mission board, despite having multi-day expiration timers. I didn't see anything useful in the log, but let me know if there's any info I can send you. I haven't yet tried recreating this in a clean install, using only contract configurator and the bases and stations pack. I might do that over the weekend.

Hmm, alright I'll x-post to their thread.

Same here. I have a few contract packs installed, and only Bases and Stations is effected. For me, missions to launch a station will become available and then disappear within a few seconds. Clicking on the "Launch a Station" mission when none are available shows all criteria met except for "Target Not Sun". The behavior looks almost like it's still re-rolling the contracts after they appear on the mission board, despite having multi-day expiration timers. I didn't see anything useful in the log, but let me know if there's any info I can send you @linuxgurugamer