Snark

I don't think "how many times the wheels have turned" is even a thing, but that's also not how I'd even try to do it if I were making an odometer mod. I'd make the odometer be GPS-based, same as how the odometer app on my phone works. Basically, just make it take a series of GPS "waypoints". Immediately take a waypoint when it starts up. Then, frequently check the position, and if it's more than a certain minimum difference (say, a meter or two) from the previous waypoint, then record the new waypoint and add the distance-from-previous-waypoint to the odometer total. Store the last-waypoint and odometer-total numbers as a persistent value on the vessel (or on the odometer part, if you prefer). There, done. I don't see any reason why that wouldn't work.

Yah, the problem is that your CoM is too far away from where all the drag happens (those heatshields). Put simply: You want your center of mass to be at the same end of the ship as your center of drag. Your problem is that you have them at opposite ends. If your problem is that CoM and CoD are at opposite ends of the ship, then you have, broadly speaking, two options: One approach is to add drag to the retrograde end of the ship, as folks here have been suggesting (i.e. more control surfaces, airbrakes, etc.). Personally, I'm not a fan of that approach for Eve landers, mainly because you also need the ship to be aerodynamically stable during ascent, and putting airbrakes etc. at the top end will work against that. The other approach, which personally I prefer, is to put the heat shields on top of the ship, and enter prograde rather than retrograde. That way, you can put lots of fins at the back end of the ship (where the engines are), and not only do they help to keep you stable on reentry, but they also serve double duty by helping with stability during the ascent phase as well.

@Jedi_Mushroom, aside from the excellent general-purpose advice already in this thread (in particular, lots of useful links from Slashy), it may also be a useful exercise to walk through one of your attempts. For example: Pick a ship whose design you're unhappy with ("here's my ship for landing one kerbal on the Mun and bringing them back, why is it so monstrous"), post a screenshot and any relevant stats, and then there are plenty of people here who will happily offer specific and highly educational suggestions for improving it.

Screenshot, please? Reentry, when done "right", is easy and doesn't require retro-thrust or other fancy shenanigans. Reentry at over 3000 m/s is easily doable. However, when done "wrong", it can be a problem. Furthermore, there are many different ways to be "wrong"-- these include your trajectory, whether you have heat shields or not, the mass and shape of your ship. Without more detailed information, it's hard for anyone to give you specific helpful advice. There's a good chance that your difficulties are because you're doing one simple thing wrong, and fixing that one thing will clear up all your problems. A screenshot of your ship would be very helpful, along with knowing what its mass is, and how steep your reentry is (e.g. what is your Pe set to before you hit atmosphere?) In general, here are the ways to be survivable: Have a heat shield. If you have a low-ballistic-coefficient ship (i.e. lightweight & draggy) in LKO, you can generally enter without a heat shield with no problem. But for higher speeds, and/or ships with higher ballistic coefficient, a heatshield is a lifesaver. Build the ship to have a low ballistic coefficient. You want something that is lightweight relative to the amount of drag. Best case is a lightweight pancake; worst case is a heavy javelin. For example, a Mk1 command pod entering by itself, blunt end first, has a nicely low coefficient and can generally reenter just fine even without a heat shield. Don't enter too steep or too shallow. If you just dive straight at the ground, you're still going too fast when you hit the "charbroil zone." On the other hand, if you're too tentative about it and set your Pe way up in the upper atmosphere, you end up generating scads of heat without actually slowing yourself down much. The sweet spot will vary depending on your ballistic coefficient, but in general, aim for a Pe of around 30 km or a bit less, and that seems to work pretty well. Use lift. This applies especially to spaceplanes, which have all that wing surface to play with... but it also applies to wingless reentry vehicles, if they've got a cylindrical profile. Angle the ship to take advantage of body lift (i.e. so that the incoming airstream strikes the underside of the ship and is deflected downwards, generating lift). This provides a great way to increase your drag and bleed off a lot of speed, while still keeping your altitude relatively high. If you're flying a ship with heat shields, lift generally isn't a factor (you don't need it, and using it is tricky because angling the ship for lift would expose non-heat-shielded surfaces to the blowtorch). However, if you're reentering without a heat shield, you should try to use lift for maximum advantage.

There should be a stock "odometer" feature... but failing that, there should be an odometer mod. (I'm not immediately finding one, though.) Of course, not having set out to write an odometer mod myself (mainly 'coz I generally don't muck around much with rovers), it's easy to just breezily say that-- there may be practical reasons why it's actually a harder technical problem to solve than one might think.

Barring other considerations (details below), I've found that in practical terms, it doesn't really matter all that much what the concentration is, as long as it's non-zero: since it's a time-based mechanic, you can just warp ahead farther to make up for lower concentrations. I mean, in most cases, does it really matter whether it takes 1 day or 2 days to fill up your tanks? For me the answer is generally "no, it doesn't matter." Exceptions to the above, i.e. cases in which the ore concentration may actually matter: 2.5% is a magic number, if you're using the small drill, since it can't harvest below that percentage. (I never, ever use it myself, so this never comes up for me.) If you have a ship that's got drills + ISRU, and if you're relying on fuel cells to power the operation: there will be a certain minimum "break-even" concentration, below which mining is impractical because the fuel cells will eat up fuel faster than the drills + ISRU can produce it. Exactly what that break-even point is will depend on what level engineer you have running the show (higher level engineer = lower break-even point for concentration). If you're running a life-support mod, then you have time constraints involved, so you may care more about "does it take 1 day or 2 days to fill up the tanks." In practice, I've found that anything above 5% is fine. 9% is, in my experience, really high. As long as the concentration is above 5%, I find that practicality considerations (e.g. bumpiness of terrain, convenient equatorial location, hassle of doing lots of exploration to find just the right spot, etc.) tend to outweigh the actual ore concentration values. So my prospecting algorithm goes like this: Do an orbital scan to identify likely-looking spots Pick whichever reasonably bright spot looks the most convenient (in terms of "flat" + "close to equator") Land there Make sure it's at least 5% (it usually is) Drill!

Hm, interesting case. I'll bear it in mind, but it's not super high on the list right now. The issue is that it's hard to figure out a way to"multiplex" that behavior into the existing functionality without muddling things and making it too confusing. (One of my design goals for IndicatorLights is to try to keep the lights' meaning really simple and intuitive for the user; a corollary of that is a general principle of "don't try to cram too much information into one indicator.") The science instruments present an interesting design challenge: there is a lot of information around them, and there are many relevant variables potentially to consider: Can the instrument actually take a reading in the current situation? If so, what's the fractional science value available? Does this science already exist somewhere on the ship? If it's a non-rerunnable experiment, has it already run? Is the vessel commandable or not? Does the vessel have a science lab? If so, has the science lab previously processed this experiment or not? ...with all that richness of information, it took quite some head-scratching to try to find a way to boil the behavior down to something that's informative but intuitive. I only managed it by basically just throwing the science lab under the bus and pretending like there's no such thing, and that all the user cares about is returning science for points. With that convention, the simple "flashing = wants science, solid = has science, off = never mind" convention, with a color code according to value, seemed to hit the sweet spot. I may come back and revisit this in the future-- either as an actual feature (if I can figure out a good way to fit it in), or as some form of additional moddability "knobs" on the ModuleScienceAvailability indicator, so that if someone wanted behavior such as you describe, they could do it by tweaking the .cfg files to make it act how they want. (Right now there's no way to do it with just .cfg.)

Hm, interesting. Hard for me to picture exactly what you mean by "rotate so they're not sticking out at a 90-degree angle when they're retracted"-- perhaps you could post a screenshot of your ship? Without having a repro case there's no way for me to tell what's going on. That said: If you're having problems extending the antenna even without AntennaSleep itself-- i.e. just clicking the "Extend Antenna" button doesn't work-- then that's nothing to do with the mod, it's something about KSP itself. So my guess is that this isn't an AntennaSleep bug.

Moving to Spacecraft Exchange.

Yep, this is in the long list of stuff that I've fallen way behind on... really need to update the documentation.

Hi gang, I've released v1.2.1 of IndicatorLights, a.k.a. "The Fwiffo Edition". Not a lot of player-facing changes, other than a small bug fix; most of the changes are for moddability. Thanks to @Fwiffo for numerous helpful suggestions. New with this release: ModuleReactionWheelIndicator now supports IToggle and IScalar. Fixed ModuleReactionWheelIndicator bug that caused it to always flash on launch. (Thanks to Fwiffo for catching.) Added new toggle syntax. Allows saying things like "and(toggle1, !toggle2)" for color sources. Breaking change to ModuleBooleanIndicator to use the new toggle syntax. Added new "if()" color source syntax. (Thanks to Fwiffo for suggesting.) ModuleCustomBlink now has a field that can choose where to show its UI (editor, flight, both, neither). (Thanks to Fwiffo for suggesting.) Modified BL-01 light's config so that its "blink enabled/disabled?" UI is only shown in the editor. ModuleScienceAvailabilityIndicator can now specify experiment ID and "low science" color. (Thanks to Fwiffo for suggesting.) Add new ModuleEmissiveArrayController, with sample config. (Experimental module, subject to breaking change without warning in future updates. You've been warned.) Add a global "master switch" to the mod, accessible from the debug console, that allows turning everything on and off all at once; useful for debugging purposes (or if you just want to grab a screenshot without lights everywhere). /il enabled on or /il enabled off. (Thanks to Fwiffo for the suggestion, though this isn't exactly what he asked for...) So, unless you're a modder, not much to write home about, here. The ModuleEmissiveArrayController is, as I've said, an "experimental" module: it's not currently in use by any part, and I reserve the right to make breaking changes to it without warning at any time. I'm including it as a sort of "sneak peak" so folks can get a feel for some of the possibilities coming down the pike. (To help ensure that modders don't get caught unaware, I've labeled the module with an "ExperimentalController" attribute that causes it to log a warning message at run time if it gets used.) To give you an idea of some of the kinds of things that are possible with ModuleEmissiveArrayController, I've included some sample config, EmissiveArrays.cfg, in the github repository. Here's what the sample config looks like in action (don't worry, I don't have plans to actually mod the HECS2 this way!): Each of the two "arrays" is controlled by a single ModuleEmissiveArrayController, with all the animated behavior defined in color-source syntax. Caveat: I haven't documented any of the new stuff on the wiki... really building up a backlog, there. Thank you for your patience, I'll try to update the docs soon. Anyway, enjoy! [EDIT] Argh. My "fix" for the reaction wheels fixed one problem (always flash at launch), and replaced it with another, which is arguably worse (always flash when in time warp). Sigh. That'll teach me to skimp on testing. Oh well, expect a fix for that soon.

Not going to happen, for various design reasons: Any condition that's "intended to", won't be, due to the free-design nature of KSP. Players are free to do whatever they want, so it would need to handle the multiple-instances case gracefully, which is a lot of work. I don't like the idea of putting whole-ship functionality on a part. Parts are parts. Parts are not ships. Functionality that pertains to the whole ship belongs in the flight UI, not as a part. And I don't do flight UI, it's not my thing. So... given that I'm not going to implement a feature in the wrong place (because wrong place = wrong), and given that I'm also not going to implement it in the right place (because I don't do UI), then this isn't going to happen. For various reasons, I tend to put "add additional parts" lower in my priority queue than adding programmatic features. That said, I do rather like the idea of giving modders access to some sort of search-the-whole-ship functionality. In other words, I don't want to implement a part such as you've just described, but I would love it if I had enough basic building blocks in IndicatorLights that some other modder could accomplish that if they were so inclined. However, search-the-whole-ship functionality is a very non-trivial design feature, so it's not going to happen all that soon. It's doable. It's even doable efficiently, from a performance standpoint. But it's not simply doable. Implementing it "right", so that it's not only robust but also performant, will take a sizeable chunk of code. The reason it's complex: It's expensive to scan the whole ship because you have to look at every single part, which is an O(N) operation that there is absolutely no way to short-circuit. You have to iterate through every single module of every single part on the ship, and there could be thousands of parts. You can't limit it to only one kind of part because it's PartModules, not Parts, that determine behavior, and any part could have any PartModule. There is simply no way around this. It's expensive. Ships aren't static. They can add and remove parts. So the super-expensive scan has to be made at strategic moments, and cached somewhere intelligent. Yes, it's doable, but it's a complicated time-consuming feature to implement, so it's not at the top of my priority queue right now. At the cost of putting special-case code into every single part everywhere, which I am loath to do. It smells of building a solution, and IndicatorLights isn't about building solutions, it's about building Lego bricks that enable solutions. Certainly it would be trivially easy to add some sort of functionality on a part menu to toggle the global variable. But I'm not going to do it, for two reasons: I loathe UI clutter. The part menus are already (IMHO) messily, irritatingly cluttered with excessive noise that doesn't belong there. Buttons on part menus are suppost to be about the part. This kind of button is about the ship, not about the part, so I'm not going to become part of the problem. There's that issue you mention about it toggling everything everywhere instead of just the ship. I'm not okay with that. Oh, not at all-- no offense taken, and I hope I didn't give that impression. You were being completely reasonable, you were following typical github etiquette, and I'm the one who's being persnickety here. It's not your fault if I happen to be a selfish, cantankerous curmudgeon.

This mod appears to be authoritatively dead. It's for an ancient version of KSP, and the author hasn't even logged on to the forum in over a year. It's looking unlikely at this point that the mod will be revived. Therefore, locking the thread to prevent further confusion. If the author, @Kommitz, would like the thread opened up again, please let the moderator team know (reporting this post is probably the easiest way) and we'll be happy to oblige.

Yup, I've recently noticed that myself. Coulda sworn it didn't do that in the past-- perhaps something changed in the way resource flow is handled in 1.2? Anyway, I've spent some time digging into this, and have reluctantly come to the conclusion that what I want ("flash if you don't have the resources needed to do your job") isn't physically possible. Resource consumers have a "deprived" flag that gets set when they ask for resources and don't get it, and which gets turned off when they ask for resources and do get it. There's no way to clear that flag without actually demanding a resource. (It's the moral equivalent of having a queue where the only way to tell if it's empty is to try to pop something out of it-- there's no non-destructive way to check.) Perhaps, if I really really wanted to, I could come up with some hacky byzantine workaround that involves extensive reverse engineering of Squad's internal algorithm in order to try to accomplish this... but I don't know if that's actually possible, and even if it were, I seriously don't want to go there. So I'll be walking this feature back, and making it so that it only flashes in the case "autopilot = on" and "operational = false". That's a pity, because I would have liked to have it when autopilot is off, too-- that's a useful feature. (Player: "Hey, I'm trying to rotate my ship and nothing's happening! What's going on? <flash flash flash> Oh, okay, my reaction wheels are out of power." Nope, can't have that. Oh well.) Agreed, good point. Going back and looking at the code, in retrospect I have no idea why I didn't do it that way in the first place, instead of hard-coding it to "off" as I did. (IndicatorLights has grown enough now that it can be hard for me to remember the rationale for specific design decisions, sometimes... maybe I was just tired or distracted on that day.) Thanks, and that's very thoughtful of you. Actually, however, all I need is a feature request and/or specific description of the problem, and I'll take care of the coding end myself. I don't actually take pull requests; I prefer all lines of code to come directly from me. It's not that I don't trust you... it's just that my mental ability to keep track of what's happening everywhere is largely predicated on the fact that it's all me, and I'm relentlessly consistent about what I do (usually), and so if I see something odd happen, I know huge swaths of possibility space that I don't have to investigate because I know what I didn't do. For me, taking a pull request-- from anyone who isn't me-- would be kind of like if some competent, organized, and well-meaning family member of mine were to come in and "tidy up" my office for me when I'm not there. It might be a great job, and it might "organize" things nicely... but I would be hopelessly lost the moment I stepped into my office, because nothing would be placed where I put it, even if the new placement is somehow objectively "better" than what I did. Possibly, but it depends what you mean by, "all" "simple" First, regarding "all": If you mean "everything all over the ship": No, there really isn't. IndicatorLights modules generally work only in the context of the part that they're on. You can toggle the state of one controller on a part by using the output of another controller on that same part, but not from somewhere else on the ship. To make it happen all over the ship, basically what you'd need to do is to set up the "wiring diagram" of every light's controller so that it feeds to something with an action-group toggle, and then assign them all to the same action group. (If you were to use ModuleToggleLED for this, it's automatically in the Light action group, so you wouldn't have to manually tinker with the action group assignments for every individual part.) As for "simple": what you'd need to do is to wire the functionality into each individual emissive's controller diagram, by setting up an appropriate toggle controller for each one. There's currently no "master switch." Do you only want this for debugging/screenshot purposes (you mention "screenshots")? Or is it something needed for actual gameplay? The former would be easier for me to slip in than the latter-- lower bar for usability, e.g. could be something involving the debugging console, like /il on and /il off or some such. Hm, not a bad idea-- actually, more as a general principle of allowing folks to decide for anything with a UI "do you want this in editor, flight, or both". Let me muse on this. Hm, interesting idea. You mean add a logical-combining ColorSource syntax that would allow doing in a string what is currently done via an explicit ModuleBooleanIndicator. Again, not a bad idea-- let me think on it. However, it's worth bearing in mind that even having that wouldn't, on its own, solve your current problem of wanting a global switch, since all ColorSource parsing is done in the context of the current part only. Adding some sort of functionality to allow specifying "search the whole ship" instead of "search the current part" may be possible, but it's nontrivial (requires wiring in lots of event-handling, since parts can move around as ships dock, undock, stage, etc., and scanning a whole ship can get computationally expensive since ships can be very big). I'll think about it, because I like the idea-- if architected correctly, it could open the door to all kinds of interestingly flexible design options. It will take some time, however, and no promises-- it's not something I can just "slip in". In any case, if a simple "global mod enable/disable" switch accessible via the debug console would solve your use case, that would be a lot easier to add. A side note: I appreciate your desire to be helpful, but please be careful about licensing requirements. Your current download link violates the license, and I'd appreciate it if you could either delete the link or fix it so that it legally complies. Details in spoiler section.

For certain definitions of "real", yes. https://en.wikipedia.org/wiki/Bussard_ramjet Larry Niven was fond of using them a lot in several of his stories.

I'm not at a KSP computer right now, but just eyeballing your config, it generally looks pretty good. However, I note that where you set up the ModuleScienceDataIndicator modules, you're trying to set a field named "experimentId". However, the field is actually named experimentID, not experimentId. "ID", not "Id". I don't know exactly how ModuleManager maps text values from .cfg files to actual member fields on C# classes, but I'm guessing it's case-sensitive. If that's the case, then what you're doing is setting a nonexistent field "experimentId" (which I assume MM just ignores), and leaving experimentID at its default null value, which causes the module to follow its default behavior of "just pick the first one you see."

Gosh, that's a great idea. I wonder, why didn't I think of that? I generally prefer that people download from SpaceDock rather than github, if possible, which is why I don't go out of my way to publicize the github download. (It's not hidden or anything-- it's right there, a top-level folder clearly labeled "release" in the github repository, which is directly linked from this thread's OP.) The reason why, as a mod author, I prefer that folks use SpaceDock where possible: it provides really nice feedback (see the "stats" graph) that lets me see how many people are downloading, which is nice to know (helps me gauge demand). github, by contrast, has no such visibility at all-- I can't tell whether the number of downloads is zero or a million. No, am not going to directly tie into Trajectories (or any other mod). My mods are generally standalone, with minimal dependencies, and I prefer to keep them that way, for various reasons which for the sake of brevity I won't go into here. Also, BetterBurnTime isn't a navigational aid. It's a "can I burn" and "how long do I burn" tool. That's it. Doing what Trajectories does is a lot more complex, and I would never, ever, under any circumstances even dream of trying to give you any information about getting down to the surface from orbit. If-and-when I do ever add atmospheric functionality to BetterBurnTime, it'll be focused on that crucial last minute-or-two before impact landing. In short: there's very little overlap between what Trajectories does and what BetterBurnTime may someday do. Trajectories is primarily concerned with "from orbit until almost-at-the-surface"; BBT is concerned with "from almost-at-the-surface until touchdown." So not a lot of help there. Yup, that's not supported in BetterBurnTime, and it's pretty much in the "ain't gonna happen" category-- sorry. It's not a bad idea, and thank you for proposing it; but there are a couple of good reasons why BBT does't support RCS: First, it would be a large and complicated chunk of code. There's a lot of complexity there, would have to deduce the placement of RCS thrusters, look at their multi-nozzle configuration, deduce which amounts which nozzles of each thruster is going to fire when they're not lined up perfectly (which requires reverse-engineering Squad's algorithms), etc. Given how big and complex it would be, I'm loath to take on such a large project for the under-1% use case that people actually want to do this. (I'm also kind of curious what's your reason for doing this-- I'm having trouble coming up with a monoprop-tank-and-linear-thruster-port scenario that wouldn't be better served by an Oscar + Ant.) Second, it would make matters worse for 99% use case of folks who don't use RCS as part of their burn. If BBT were set up to "assume that RCS will be used, if available", then the burn times posted would be off, because they'd be assuming that people are using their RCS, too, which is generally not the case. So, that particular feature's probably not on the table.

Moving to Gameplay Questions. What you are asking for isn't physically possible: thrust requires reaction mass. Therefore, there's nothing in the game that will allow you to do this. The closest you can get with the stock game is the ion drive, which has an Isp much, much higher than anything else in the game... but even that consumes xenon. That said, I wouldn't be surprised if there's some very science-fictiony mod out there that could have some magical reactionless drive to use. (Yes, I know of the theoretical possibility IRL of solar sails, photon drives, etc. But they don't exist in stock KSP, and even in a mod, they'd be impractical for gameplay unless performance were exaggerated to levels that make the ion drive look like stark realism.)

From chatting privately with one of the devs. In KSP 1.2, ModuleColorChanger was added to the "old-school" crewed parts (like the Mk1 command pod), which gave us cabin lights... but happened to completely break IndicatorLights on those parts. Was asking a dev about it. It turns out that there's a feature includedRenderer and excludedRenderer on that module that gives the part to specify specific meshes not to be controlled by ModuleColorChanger. So I added excludedRenderer for my meshes, to prevent my module from arm-wrestling with Squad's. It's a ModuleManager wart. Whenever you add a mesh to a part via ModuleManager (like this), it turns out that ModuleManager actually appends the word "(Clone)" to the end of the name of the mesh in the part. I have no idea why it does this, it just does. In most of the IndicatorLights config, you never see this, because I've specifically added IndicatorLights code to deal with the "(Clone)" thing. By doing this, I can hide that detail from the user, so you can just say things like this without having to insert a silly "(Clone)" all over the place. However, in the config line that you noticed, I can't hide the "(Clone)", because I'm giving a directive to a stock Squad module and I need to tell it the actual, literal name of the mesh on the part. Alas, no. It's only a specific thing to ModuleScienceExperiment. I wouldn't have a clue about the ModuleAnimateGeneric issues you're running into. Mainly that "brighten" felt weird to me when it could be actually dimming. "brightness" struck me as more neutral. Because it didn't occur to me and nobody mentioned it until now. See, not all answers have to be complicated. (Yeah, I should add that.) It just iterates modules on the part and picks the first ModuleScienceExperiment it comes across-- the same way that ModuleScienceDataIndicator used to do, before I added the feature to allow specifying experimentId. I just need to add that feature to ModuleScienceAvailabilityIndicator too.

No, it's very lightweight. It shouldn't affect your performance at all. I really cared about perf when I was writing it, so I took great pains to try to ensure that it treads as lightly as possible. Programmer technobabble, with some examples, in spoiler section for anybody who's interested. The TL;DR is that no, it's not expensive. It's very cheap and lightweight. Not only did I set out to design it that way, but also I've never once had any complaint about it (which is saying something, given that there are literally thousands of people using it-- it's my most popular mod by far, is currently the #16 most-popular downloaded mod on SpaceDock). If there were a serious issue, I expect I would have heard something about it by now.

Except that I don't use the camera for docking. At all. I use Navball Docking Alignment Indicator. I have so little use for "Aim Camera Here", and get so constantly irritated at all the extra and (to me) useless clutter in the part action windows these days, that I'm seriously considering writing a mod to allow removing them in some configurable fashion. I use "Aim Camera Here" so rarely that I would rather just have the button deleted from all menus, thus reducing clutter. Ditto auto-strutting and rigid joint options.

Saw the topic title, showed up to pontificate on the subject, saw that I've been efficiently and effectively pre-empted. So, never mind. (Though, TBH, what always bugged me the most about the stock "estimated burn time" display wasn't the fact that the timing was off, it was that nagging persistent "N/A" all the time. That, and not knowing whether I actually have enough fuel for the burn I just set up. The latter two were what really prompted the mod, more than the burn time itself.)

I may be the only one here who hasn't been turning handsprings over 3D mouse in KSP. Nothing against it; just find that I don't have much use for it. Which surprised me, because before I had one, I was super jazzed about the prospect. I got a 3D mouse (the Connexion SpaceNavigator), went into KSP all excited, spent about 15 minutes going ooh ahh in amazement... and then just kinda shoved it to one side and have barely touched it since. It's not any great dramatic epiphany, nothing against it per se... I simply find that I get along just fine in the game without it, it doesn't do anything that I really need on a day-to-day basis. Sure, it's cool that the camera can swoop around ... but I never find myself wanting to swoop it around; the stock mouse-based camera controls are plenty for me. About the only time I ever end up using the 3D mouse in-game is when I want to position the camera "just so" to set up an illustrative screen shot for one of my mods... and now I don't even need it for that, with 1.2's new "Aim Camera Here" (which is, incidentally, another feature I find I have no use for, ever, except for that one case of setting up a screenshot for a mod.) The one thing that I do find the 3D mouse absolutely indispensable for is when modeling stuff in Blender. I'm a total fumblethumbs in Blender, even with the 3D mouse... but without it, I'd be far worse; would probably push me over the edge from "clumsy" to "frustrated ragequit".

Hi all, I've released v1.2 of IndicatorLights, a.k.a. "The Antenna Edition". Three guesses what's in this one. All antennas now have an indicator that lights up while science data is being transmitted. The light has a random "flicker", like old-style modem lights. The speed of the flicker is tied to the transmission speed of the particular antenna: faster antenna = faster flicker. (Thanks to @Beetlecat for suggesting the feature.) Note that the screenshot above is for illustrative purposes only, and isn't typical of what you'd see in-game. Normally you'd never see that many antennas lit up at once, unless you happen to have scads of science data and everything's actually transmitting simultaneously. Here's what it looks like in action: Besides the antennas, other changes in this version include: Fixed a bug that caused IndicatorLights-enabled meshes to break the thermal overlay display. (The Science Jr. was especially bad, since it affected the whole part. Most parts, it's just the actual indicator meshes themselves.) Added some new "scalar" parsing syntax for more flexible configurability of color sources. (This is of interest mainly to modders; the idea is to enable certain modules to declare "scalar fields" that can be referenced in ColorSource syntax. It's how I get the antenna lights' flicker speed to be automatically tied to the antenna's data rate. I've fallen way behind on updating the "modder's guide" documentation... this feature will make a lot more sense once I've had a chance to update the docs. Thank you for your patience.) Enjoy!

Hi folks, I've released v1.5.1 of BetterBurnTime. Changes in this version: Fixes a bug that caused BBT to spam NullReferenceExceptions to the log when impact-tracking if there's a kerbal in a command chair. (Thanks to @brusura for pointing this out, sorry it took so long to get around to fixing it.) Adds a new API class to export the data that BetterBurnTime calculates in a way that other mods can have access to it. (Thanks to @richfiles for requesting, and @stibbons for clarifying.) The new data-access class is called, perhaps unimaginatively, BetterBurnTimeData. It exposes the following bits of information: What "mode" is it currently in? i.e. info about what? One of: Maneuver, Impact, Rendezvous, None. Burn time. dV needed. Time until event (maneuver node, impact, or closest approach). A boolean warning flag indicating "insufficient fuel" or not. Mods wishing to use this class can take either a "hard" or a "soft" dependency. A "hard" dependency is where the 3rd-party mod has an actual assembly reference to BetterBurnTime.dll (such that the other mod won't even load unless BBT is present). Such mods can access this class via the static property BetterBurnTimeData.Current, and then programmatically access the fields directly. A "soft" dependency is where the 3rd-party mod treats BBT as an optional requirement, and detects it at run-time. The code for such mods isn't quite as simple as the hard-dependency case, but it's still pretty straightforward. I've included a sample code file, BetterBurnTimeDataExample.cs, in the github repository for the mod. You're welcome to use that as a starting point, if you like. It demonstrates how to get data out of BBT as a "soft dependency" via BetterBurnTimeData. (The example simply pulls the data every two seconds and writes the data to the log file.) Enjoy!