Entropius

@BigD145: I definitely replaced all the folders' contents with ATM's reinstallation. In fact I can still see the empty folder from the compressed archive that I moved them out of. Nothing was left out. If needed a log is available here. In the BoulderCo folder I did notice that neither KER, FAR, nor RCSBalancer have any config file in BoulderCo, while TriggerTech does (and that's the set of addons that aren't affected by the icon bug). Maybe that has something to do with the problem. And Alternate Resource Panel is a Trigger Tech addon, which I pointed out were not affected by this bug, so the fact you don't see a problem with that addon doesn't actually disagree with my observations. Master Tao: Setting scale = 4 while keeping KSP's texture quality at normal ends up using way too much RAM for me, 3.00 GB by the time I get to the main menu (which frankly I can't work with). Meanwhile I was around 2.1 GB with the KSP texture quality setting set lower. I know for certain back in KSP 0.24.2 with ATM, I could set KSP's texture quality to half or quarter, get reduced RAM usage, AND not corrupt toolbar icons. The RAM reduction and Toolbar icons both worked. But not now.

Half res & quarter res are both affected. Other texture qualities might be affected too, but if so I wouldn't know since I haven't tried them.

If the cache you're alluding to is the one in the ATM folder, then yeah, clearing that does nothing. And I've fiddled/reset my KSP.app (not .exe, since it's a Mac) graphics settings plenty lately. As for the icons being larger than a certain cutoff (which is an unfamiliar thing to me), FAR's icons (blizzy & squad) are respectively 503 bytes and 602 bytes. KER's icon is 1 KB. RCS Balancer's are 1KB. Transfer Window Planner's is 1KB. Alternate Resource Panel's are 162 bytes (biggest). So I'm not really seeing any correlation between icon size and ATM's behavior here.

No, the fuzzy-toolbar issue hasn't been fixed. Toolbar icons (both toolbars), remain exceptionally fuzzy, to the point that you're basically guessing as to what you're clicking on. Curiously, the problem only afflicts certain toolbar icons. Afflicted icons include RCS Balancer, FAR, KER. Unaffected icons include Alternate Resource Panel, Transfer Window Planner. (edit: it should be noted the unaffected icons are both TriggerTech mods) http://i.imgur.com/WPH1ppn.png

I'm looking forward to this eventually being a usable part. I've wanted a non-ablative (reusable) heat shield for a while, so that I can have reusable landers for places with atmospheres.

Mind explaining how to go about doing that?

In KSP 0.25, lateraltrons are bugged in a way that makes them appear several times larger than they should be. Is a solution for this possible? EDIT: So I came up with a temporary solution until an official update fixes it: Create a Module Manager cfg file that contains the following: // Fixes size of lateraltron in KSP 0.25 @PART[lateraltron]:AFTER[aWolf] { rescaleFactor = 0.08 }

Anyone else notice ground-shadows no longer appear in 0.25? Performance also appears to have dropped severely (which is disappointing because 0.24.2 with Yosemitie was running silky smooth).

Yup you nailed it. It reset my graphics settings to use higher res textures than I previously had. Thanks! And yes, I have a ton of mods that use lots of RAM (I blame RoverDude). Although again, many of them are tiny, and ones that you'd expect to be huge were pruned down to just a handful of parts. Here's a screenshot of the GameData folder, sorted by file-size.

Update: Reinstalling TweakScale removed the incompatibility warning on the startup screen. But KSP invariably crashes in the same place it previously did. Log mentions running out of memory, but I can't fathom why, the mods are simply updated versions of mods I already had. And many of the mods were pruned to remove unnecessary parts (like B9 which is only about 5 parts).

I just updated KSP to 0.25, along with mods as well. I get a warning on the start up screen that an addon named "Scale" is incompatible with KSP 0.25. After the initial progress-startup screen but before the game's main menu screen, I crash. Player.log and a screenshot is available here: https://www.dropbox.com/sh/qyh7awtl24wtj4z/AACu0Kt-HcVHf15pILG4PfYda?dl=0

When Female Kerbals are added, be sure to make at least one a permanent, respawning, orange-suit character.

Oh man, I haven't tried to use them since that update apparently and it does exactly what I wanted already. All hail Rover Dude!

Awesome. By the way, I love the mod. If I might be so bold, there's a feature suggestion I like to offer in case the idea hasn't been considered yet: Give the ducted fans action-group options for "toggle hover" (locking you to a radar altitude), and "increase height" and "decrease height". B9 has a VTOL engine called the Engine_VA1 that does this, and I love it, but I'm pretty sure that hover functionality came from Firespitter, which is already a dependency for USI Exploration. Or at least I see such functionality noted in this Firespitter document. As best as I can tell, the hover function works by rapidly turning on/off the engine depending on your height relative to the target height (since it doesn't appear to work via throttling). Just an idea… maybe not a great one. It might cause me to crash fewer craft using those ducted engines though.

I think I found a bug. USI Exploration pack's manned command pods (all 3 of them) seem to suffer from some confusion when the command pod is not the root-part. In my screenshots, the root part is the probe-core (to which the front girder-leg attaches to).

I've noticed my 2 smaller Fusion drives appear to have a problem with their attachment nodes. There's a large gap both above and below them. The largest (2.5m) fusion drive appears to be okay. http://imgur.com/a/hW5mL Any idea why or how to fix it? I'm pretty sure I'm running the latest version of everything, as the addon-version checker doesn't seem to be complaining about any USI mods. K+ is at version 2.1.

In the latest version, I noticed 2 things happening: (1) Laggy performance on the Map View and (2) My debug log was getting spammed with orange text messages like “Mesh.vertices is too small. The supplied vertex array has less vertices than are referenced by the triangles array.†Removing the mod appears to make the problem go away, so I'm pretty sure it's Atmospheric Trajectories at work. Also worth noting, that disabling the trajectory drawing option via the toolbar button didn't stop the symptoms.

Sorry, no dice it seems. Doesn't work. I checked the debug log and the Player.log, and nothing interesting regarding Fusebox seems to be there. I'm using Mac OSX, but KSP addons are usually platform-agnostic, so that shouldn't be relevant.

Hmm, I just tried your linked dll, but it's apparently still not working.

When I click the "Pick" button to change it to a body other than Kerbin, no new window appears (as seen in the 1st page screenshot), nothing happens. Any idea what's going on?

Ferram, could it ever be technically feasible for FAR to predict the aerodynamics of not the whole craft, but of just a future stage of the craft? I'm curious because if it could be done, then Atmospheric Trajectories could then figure out a reentry path of a capsule without having to decouple the capsule from the craft (possibly at the expense of losing one's engines). I'm guessing the answer is no, but I thought I'd ask just in case.

@Kerbin, We Have a Problem, as per Gaiiden's suggestion, here's an alternative version that relies purely timing for ending the burn. http://pastebin.com/skBnC7fH Since it doesn't throttle down slowly near the end, you're going to have to make sure the burntime isn't too short on small maneuvers. If it is too short, use a thrust limiter to force the burn to take longer.

My script actually does calculate the burn-time, it just doesn't solely rely on burn-times alone. This is because when I did rely on burn-times alone, I'd randomly run into problems where on extremely rare occasions, the script would fail to end on the designated time, and burn until I killed the script. So I added 2 criteria for ending: (1) timing out or (2) overshooting the ∆v and seeing it increase (a redundancy/fail-safe). Maybe I just have to either accept rare cases of over-burns or no-burns. EDIT: I take that back, I don't actually rely on timings to end the script (just when to begin the burn), you're right that it's looking to ∆v. My memory fails me yet again… Anyway, if I use strictly JUST timing to end it, I'm not sure how I'd know when to do the slow-burn throttle, which would seem important since a very high-thrust engine may overshoot the target a bit if at full throttle. Maybe I'll play with it a bit, but ultimately I'd still like to figure out why the current approach randomly fails, even if another approach might work.

I have a script that executes your next maneuver node. It seems pretty reliable, like 95% of the time, but on rare occasion it fails to start the engine burn at all and just ends early. I'm not sure why, and if it's due to a bug on my end, or kOS's. (If anybody has any insight into that, I'd love to hear it). EDIT: I just realized in my code there's a comment warning that it doesn't work with thrust limiters, but it actually does handle those now, so disregard that line.

Holy crap, I actually did it! I landed at the KSC in a capsule decoupled from orbit (and deadly reentry to boot). I also did it on the first try no less. And I think it's safe to say it was largely thanks to this mod. Now I will note that the accuracy wasn't perfect, I couldn't blindly trust it, as the ground-marker (cross) drifted quite a ways across the continent as I reentered (first drifted short of the target, then drifted back toward the target), but between my meager RCS fuel and some adjustment of my angle of attack, it was enough to hit my target regardless of the unexpected drifting. It's good enough to get the job done. I've waited a long time for a mod like this. Some suggestions for the future: It would be nice if it could update your ship's drag, not based on the ship's current stage/state, but rather a future stage. That way you could get your orbiter into a desired trajectory without having to first decouple the capsule from it yet. (But I'm not even sure if this is possible from a technical standpoint, maybe not). Figuring out what causes the ground-target to drift would be nice. The accuracy proved to be good enough, but more accuracy would always be welcome to have. Also I still have a question though: On the descent profile, what do "entry", "high", "low" and "ground" mean exactly?