jinks

Took me a few days to get back to this, but it definitely fixes the problem with WBI Engines. Thank you!

Fantastic! You already managed to identify the (likely) problem. I'll keep an eye in the issue.

https://forum.kerbalspaceprogram.com/topic/154893-min-ksp-1122-mark-one-laboratory-extensions-mole/page/46/#comment-4208790 is a good start. I can provide you a screenshot and logs in a few hours, but the logs didn't yield anything obvious when greping through them...

I am still having this issue and it's being reported by multiple users on the WBI thread. I already disabled all plugins (via ModuleManager config) mentioned in the settings file and the error still persists, so it's probably something that can't be turned off. Only fully removing KFSPCF fixes the upgrade issue.

Perfect!

Sure, no problem. A bit cramped, but it should show what you need. 4 stationary sats with 2 "clients" in low orbit and the 3 Mun sats connecting. They use the "Kerbin" (1300) constellation among each other and talk to ground via a direct connect over the AX-04 (Near Future antenna, direct, 40k rating).

YES! That's exactly what I thought. Sorry I couldn't word it better in the first place. Curiously my satellites around Kerbin don't do that, they have pink lines between each other and blue (999, DSN constellation) lines down to the ground stations.

It's not about the signal strength, it's about the constellation color. Here's another picture where I avoided the green->yellow->red colors: Each of the three equatorial sats has 2 antennas: The DTS-J1 is a 2.00G direct antenna connecting to my relay sats in Keostationary orbit. The HG-32 is a relay antenna maintaining the Mun network. What I don't get is, why the the three equatorial relays have pink lines between each other. Their pink antenna should only be able to connect back to the Kerbin constellation. The unrelated polar satellite properly uses the purple constellation to relay through the mun network. I would expect the relay sats to have pink lines back to Kerbin and purple lines to each other.

Only a contact pack and some extra antennas. Can you test again with the direct antennas and some relays on another channel? - I don't think it creates wrong connections, I think I only colors the relay connection wrongly as the primary network.

I think I have found a minor visual bug... In the above screenshot you see 3 sats of my Mun network. They have each one direct antenna, connected to the Kerbin network and one relay antenna to the Mun network. Direct antennas cannot connect to each other, so the green lines forming a triangle around the Mun should not exist. 2nd screenshot: Mun network visible when Kerbin Network is hidden. I'm using the CKAN 1.5.7 version.

Can anybody tell me, why TCA does this: https://i.imgur.com/8WlqBJK.mp4 ? When I launch manually and then activate TCA a few meters up, this doesn't happen. So why can't I activate ToOrbit directly from the ground?

As far as I can see in my (early midgame) career save, HC got a "nerf" of a factor of about 3x to 5x, Squad parts are down by a factor of 20x to 30x (50kW to 2kW or 150kW to 5kW for example), which feels a bit too much. While I like the concept of heat loops, some other aspects make me think that SH, in its current iteration, is not for me. I'm not sure if it's helpful, but here's a few things I disliked during testing (in no particular order): The weak radiators give the impression that they encourage part spam for no particular reason. The removal of the NFE reactor control panel. I really like that one. The fact that I will have to deal with two (or more) competing heat systems for an extended period of time (I have a lot of mods, it's unlikely many of them will be integrated any time soon). I think for now I will stick to vanilla and use SH in FFT only mode (which is a ways off either way at the rate my Kerbals are advancing).

Just to get my head around this, is this mod supposed to massively increase part count? I tested the NFE UX-0 KerboPower with vanilla and with SH and my radiator count went from 2 "YF-15 Volta" from HeatControl up to 10 of the same to keep the reactor cool.

I have a small feature request. The mod already dynamically modifies LF/Ox tanks to support LH2 and LH2/Ox. Could you do the same for LF-only -> LH2? I have some mods that add pure LF tanks for use with the LV-N. Given that I play with about all of your mods, LF for nuclear rockets is pretty much useless.

My train of though was that some kind of erroneous oceanic resource may trigger something inside KSP that then reports to Scatterer that Minmus has an ocean when it shouldn't.

It is. Something I just noticed: When browsing through KerbNet ore maps, one of the options I get is LqdHe3. This sounds like an ocean resource but I'm not sure which of my 150 mods adds it. (Give the large number of mods I am loathe to do intensive bisecting on this, I'd rather not have refraction shaders until this solves itself. ) Also, since I forgot to mention this in m last post, I'm playing on Linux.

I've found Filter Extensions to be quite helpful in that case. It sorts the manufacturer tab by mod folder name instead of the free-form manufacturer tag in the part file.

Just to add a data point: I've tried the experimental .dll and still get NullRef spam on scatterer.RefractionCamera.OnPreCull () when switched to a craft on Minmus. From the mods I'm running i think the relevant ones are EVE, Galileo's OPM and SVE.

Might also be me doing something wrong... I tested with the stock CommSat LX, and TCA flipped it a few times when I set steepness too low. kOS gets the AP to altitude when the ship is still only at 30,000m up in some cases so it matters a bit at least. The script is relatively simple in its behaviour. Point to surface prograde until out of atmo, then point to node. OK. I thought TCA might probably not try hard enough to turn because it thinks it can't. - Then the kOS script probably gets its advantage from leaning in very hard early on when the low speed doesn't pull you back to prograde so hard. Some of my heavy lifters have 6 or more stages. The stages are usually pretty simple, 1 big engine pointing out the back and 2-4 solids pointing forward to drop it back to the planet after separation. What I see with TCA is that I have to create 6 profiles, set the active stage on each profile and then make sure only the backfacing engine for that stage is set to ON. - I'm currently in an "expansion" phase, so I launch a lot and I usually build custom launchers for each ship, maybe I just notice it more because of that. Mechjeb or the linked script make the process a lot easier because they don't manage engines. They just stage and work with what's available. This is obviously not as easy for TCA, but I find that I often only want the full capacity of TCA after the launch sequence is over. I don't really have a solution that won't cripple the main functionality of TCA and/or make it more tedious for the not-launch case. A few random ideas: First time on the pad the ship is in PRELAUNCH state. As far as I know that state can never happen again later for a ship. Maybe use that as a trigger to turn off some management? While in ToOrbit mode (and on the first launch as determined by PRELAUNCH), ignore all stages except the current one, don't try to manage (turn on/off) engines, just throttle them as per usual. As soon as ToOrbit is done it can forget all about the above since it'll never happen again. That should make it at least somewhat simple code-wise. Two branches selected by a single external variable. On another note, the landing sequence from TCA is the best thing I have ever seen. Neither Mechjeb nor even Trajectories come even close to the accuracy with which a TCA controlled ship puts me on-target.

I'm having a bit of trouble trying to get TCA to launch my ships to orbit... First: Do I really have to micromanage every single ships launch configuration? I have to create a separate profile for every single stage of a multistage launch or TCA just turns engines and spent-stage retroboosters on more or less randomly. Second: No matter what I do, TCA always launches ships at a very steep angle and wastes tons of dV on getting up to orbital speed. Up until now I have used this kOS script for launches (GitHub), but well, it's kOS, so quite a resource hog (it takes about 7-8 seconds alone to compile an start on launch) and it means I have to include and manage kOS parts on every single ship. But that script gets me into orbit for several hundred m/s of dV less than TCA. As an example, here's the trajectory of the same ship right after it turned off the engines to coast to AP. Once launched with TCA (steepness 10%) and once with the kOS script Some observations: the kOS script turns much more aggressively early on, going to a 50° trajectory at about 5km up the KOS script keeps the nose on prograde instead of on the circularization node while coasting to minimize drag TCA constantly complains about low control authority. - My ships rely on control surface fins for atmo steering, does TCA not recognize those? What can I do to make TCA behave more like the linked script? And can you maybe have a look at the math in that script to improve TCA's gravity turns? (It relies on an exponential curve which has, so far, worked for every ship I've thrown at it.) As a side note: ToOrbit parameters revert to 71, 0.9, 50% on every launch. Is there a place to set different defaults?

KSPI only supplies the active vessel, which is fine in my book. Catch-up is probably "good enough"™. Transmitters could store their max generator capacity, no relay-transmitter hybrids and for LOS checking and inverse square law we already have a working CommNet which could probably be hooked in some way. I'm not looking for a complex system-wide power distribution network that takes all the moving parts into account. I'm quite fine with "which transmitters can this vessel reach and how much can they supply right now". My two main use-cases are light probes that can run on beamed electrical power instead of heavy reactors or panel spam, and to "route solar power around occlusions".

That's the bit I missed.

I'll put in a few spoiler tags just to be sure... Turns out I interpreted the numbers wildly wrong and just warped through the relevant region. From past posts I assumed min/max altitude of 40 meant Sun radius * 40 which would come out to roughly 10.7Gm, but there was nothing there. I finally found the band at about So I'm not quite sure how to interpret the values of 40 and 5 for altitude and range in any way that correlates with the sun's radius and the results in-game.

I'm having a really hard time finding Karborundum anywhere around the sun. Looking at the current config (Min/MaxAlt=40), the numbers I come up with are somewhere between Kerbin and Eve, which is wildly different from what old posts tell me, but afaik the config has changed several times since then. I'm playing with Galileo's OPM, but as far as I can tell it only adds Karborundum to a few places and doesn't touch the solar values. Am I doing something wildly wrong?

For me, the use case is usually temporary parking. I.e. I have a crew on engineers that need to do some construction and I don't want to leave their transport drifting in space. The station core is at this point just a cupola and a 6-way hub covered in construction ports. For a normal rocket I can just use a construction port and not weld it, but this excludes spaceplanes and inline ports. Another case that I had happen once was that I had to shuffle some modules around and the ports (a mix of normal ports for ships and construction ports for future expansion) would not line up in any way so I could park that module to make room.