• Content Count

  • Joined

  • Last visited

Community Reputation

27 Excellent

1 Follower

About jinks

  • Rank
    Spacecraft Engineer

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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?
  8. 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".
  9. 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.
  10. 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?
  11. 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.
  12. This is probably the wrong topic, but since MKS contains the PDUs it's the only good place I can come up with. @RoverDude, several years ago (2014) in the Alcubierre Drive thread you alluded to *maybe* doing something with beamed power, has there ever come something of that? Right now the only option for beamed power in KSP is KSPi, which comes with a lot of baggage. I'm looking for something simpler and "more Kerbal". All I want is a reason to dump some solar satellites in a low orbit and have them them be useful. So, just as an open-ended question, how hard would it be to slap together the PDU code with the CommNet relay/LOS features of stock and have a *simple* beamed power system that can move EC from near Kerbol to my drones near Eeloo? Is this something that fits with USI suite, or should I rather pose that question towards @Nertea and his Near Future line of mods? (I kinda feel guilty throwing just another mod idea your way, so don't feel obligated to even think about it. )
  13. Nah, I'm good. Just making sure I'm not mission something obvious. I'll inform HR to act accordingly. Time to do some field testing... I's a bit vague, but sure. Edit: #1362
  14. I'm still trying to wrap my head around the whole Logistics process... There's a few questions that have come up: It seems I need to include a "dummy" logistics part on an unmanned miner in order to make it interact with PL. So far I've seen the MPU (expensive, light) and the Duna and Tundra logistics parts (heavy, Duna's cheaper) work for this. Are there any other parts to tie in a remote miner to the PL system? Do Quartermasters have the same range extension feature as pilots, or do they fulfil only other logistics duties? "Remote" power: The microwave transceiver only lists a range on the sending side. Do I need a microwave transceiver on the power rig and a normal PDU on the receivers or do I need microwave on both ends? I'm definitely having a blast planning out my first outpost and trying to make it fully self-sustaining. Bases actually having a purpose is so much more fun. Also, something of a bug/inconveniece that has been mentioned before, but nothing came of it: If I try to use one of the switchable miners there are several large pauses involved. Once when picking the part from the list, once when attaching it to a ship (pause increases for more symmetry parts) and once when clicking deploy in the field (not on start drilling, though). KSP just freezes for about 20 seconds and one CPU core gets pegged at 100%. The pause seems to be a bit shorter on the MEU-100 vs the MEU-500 and strip miners. I can reproduce the problem with only the USI suite and CRP present on a test install. My best guess by observation is hat "something" gets thrown into a serious loop when trying to enumerate all those drills. There is absolutely nothing at that point in either the KSP.log or Player.log.