Snark

Moderator
  • Content count

    5127
  • Joined

  • Last visited

Community Reputation

5649 Excellent

About Snark

  • Rank
    E Pluribus Boojum

Recent Profile Visitors

7009 profile views
  1. Excellent, thanks for taking that on! Continuing this discussion over on the IndicatorLights Community Extension thread, since that's generally the place to talk about IndicatorLights compatibility patches with other mods.
  2. Continued from the main IndicatorLights thread: Well, I've never used the "construction ports" you mention, so I don't know what they do or how they work or what they look like. So, "use your best judgment" is about all I can say. You use the mod and I don't, so you'd have a better idea about what looks best, anyway. Out of curiosity, what functionality would the lights have? Is this something that's already covered by one of the emissive-controller modules already implemented in IL?
  3. Except... it's not completely obvious, all the time. For example, why not test a jet engine while splashed down? Clearly the idea bothers you, so presumably you have a reason-- but some other player may be just fine with it. So the part-test contracts don't bother me all that much. Probably the reason it doesn't bother me when sometimes they're kinda silly is that, well... they're always kinda silly. (I mean, seriously, you build an engine, you can test it all you want in various conditions, but it matters that it happens to be on an escape trajectory out of Duna? As opposed, to, say, a suborbital trajectory over Duna?) It's a "challenge" of varying difficulty that gives a payoff roughly commensurate with the difficulty, and personally I'm fine with that, for the most part-- main thing is that it does tend (for me, anyway) to break immersion a bit. Kinda takes me out of "I'm flying rocket ships!" and more into "I'm playing a video game." The one that bothers me more than the nonsensical part-test contracts are the flat-out impossible ones, such as wanting you to mine ore on Jool or the Sun. Those just seem like an oversight.
  4. Okay, folks, here's DefaultActionGroups v1.2.3, a.k.a. "The Errol Edition"! This update addresses a problem with the optional config for solar panels when Kopernicus happens to be installed. Many thanks to @Errol for noticing the problem, tracking down the root cause, and suggesting a fix. Enjoy!
  5. So, if you have an object that's 15x more distant from the home planet than Eeloo gets from Kerbin, then yeah, a lone JX2 won't reach. However, you have several options available to you: Combine multiple antennas. Like most of the stock antennas, the JX2 is "combinable", i.e. if you have multiple of them on one ship, they combine for greater total transmit/receive power. The JX2 has the default "combinability exponent" of 0.75, i.e. if you have N of them, then your power will be N0.75 times the power of a lone JX2. So, for example, if you had four JX2 antennas one ship, it would have 40.75 = 2.8 times the power of a lone JX2. So, if you had a ship with four JX2s talking to another ship with four JX2s, the max range would be 2800G instead of the 1000G that you get with a single JX2. Use a relay network. i.e. make a "bucket brigade" of JX2-equipped ships, spaced at intervals, so that you don't try to make the connection in a single hop. Tweak the antenna. With a simple ModuleManager patch (or just hand-editing the .cfg file for the antenna), you can make the JX2 antenna have any power you like.
  6. ....scribbling notes.... some nice ideas here for potential mods...
  7. Excellent, thanks! (Both for the heads-up, and also for taking the trouble to come up with a solution. And especially for diagnosing the root cause, because that's what would have sucked up most of my time if I'd stumbled into this on my own. A huge timesaver, major thanks for that.) Hadn't yet played a 1.3 game with Kopernicus installed. Once I have a chance to sit down with my KSP 'puter, I'll tinker with this and work it into an update.
  8. Am not in front of my KSP computer at the moment so I can't confirm this first-hand, but I believe you can kinda have-your-cake-and-eat-it-too with an alternate solution: write a ModuleManager patch that re-designates the unwanted parts to a nonexistent parts category. That way, they still exist in-game and anything that depends on them won't be broken, but you don't have them cluttering up the parts tab in the vehicle editor. Added bonus is that doing it via ModuleManager means that you're not futzing with the stock game, which means, 1. less chance of messing up your install, and 2. you don't have to re-do your effort all over again each time KSP updates. Of course, that would require you to either learn the ModuleManager syntax to make that happen, or find some kindly soul who could do it for you.
  9. The short answer is probably: it's because that's the path of least resistance for the developers. The contract system is designed to "do random thing" with enough variety to be interesting. When you make a system that's designed to emit a slew of random results, it's easy for it to occasionally emit oddball "edge cases" that don't make much sense. Therefore, making it not do that is extra work-- i.e. you'd need to design and implement a system for specifying don't-ever-do-this overrides, then someone would need to sit down and try to think through all the possible combinations that a human thinks "doesn't make sense" and populate the system with those. Is it rocket science? No. Would it take years of effort? No. But it would be a chunk of work, and they've got a lot of other features, bug-fixes, etc. competing for their attention, many of which are going to be higher-priority than this. So it's not all that surprising that they might not have gotten around to it. You could always post in the Suggestions forum, or log a bug.
  10. Or, indeed, send off the supplies *before* the main ship. Probably a bit late to be suggesting this now, of course, since it sounds as though you already have everything thoroughly planned out. But just for future reference: You can significantly mitigate risks to crewed missions by sending uncrewed ones to blaze a trail. For example, say you send an uncrewed ship that delivers a hefty cargo of fuel and life-support supplies to Vall orbit. (Or even just orbit around Jool.) This kills two birds with one stone. First, it gives you excellent practice at making the transfer, without risking your crew-- if you screw it up, you're only out a few thousand funds. Second, once you've accomplished that, it makes your crewed mission safer; e.g. if it turns out that you don't have quite enough dV or life support with you, you can re-load from the supply tanker that's waiting for you at your destination.
  11. The short answer is, "whatever you want." You can do practically anything... it's really a question of what you like. Different people like very different things. Hard to give useful advice, therefore, without knowing where you're coming from. Can you elaborate about your thoughts, here? What's your dilemma?
  12. Hi all, I've released v1.0.2 of AntennaSleep. No new features, this is just an update for KSP 1.3 compatibility. The main thing that's changed is that it's now bundled with the newest version of ModuleManager, 2.8.0, so that it'll work with KSP 1.3. One other change is that I've updated it to target .NET framework version 3.5, as a KSP mod is supposed to. Previously it was targeting 4.5.2. (This change is of interest only to modders who might be adding assembly references to this mod. It has basically zero effect on players.) Enjoy!
  13. Hi all, I've released v1.2.2 of DefaultActionGroups.. No new features, this is just an update for KSP 1.3 compatibility. The main thing that's changed is that it's now bundled with the newest version of ModuleManager, 2.8.0, so that it'll work with KSP 1.3. One other change is that I've updated it to target .NET framework version 3.5, as a KSP mod is supposed to. Previously it was targeting 4.5.2. (This change is of interest only to modders who might be adding assembly references to this mod. It has basically zero effect on players.) Enjoy!
  14. Hi all, I've released v1.3.1 of BetterCrewAssignment. No new features, this is just an update for KSP 1.3 compatibility. The main thing that's changed is that it's now bundled with the newest version of ModuleManager, 2.8.0, so that it'll work with KSP 1.3. One other change is that I've updated it to target .NET framework version 3.5, as a KSP mod is supposed to. Previously it was targeting 4.5.2. (This change is of interest only to modders who might be adding assembly references to this mod. It has basically zero effect on players.) Enjoy!
  15. Hi all, I've released v1.2.9 of IndicatorLights. No new features, this is just an update for KSP 1.3 compatibility. The main thing that's changed is that it's now bundled with the newest version of ModuleManager, 2.8.0, so that it'll work with KSP 1.3. One other change is that I've updated it to target .NET framework version 3.5, as a KSP mod is supposed to. Previously it was targeting 4.5.2. (This change is of interest only to modders who might be adding assembly references to IndicatorLights. It has basically zero effect on players.) Enjoy!