Entropius

Finally! I've waited for a mod like this for some time. Thanks!

Okay, now I finally have a log demonstrating the duplicate application-launcher buttons (took a while). And here's another screenshot: Curiously, I noticed Chatterer's button was unaffected. One minor thing I should correct about my previous description of it's behavior: The duplicate buttons do appear to work. I guess I misremembered that part for some reason.

Were you adding kOS processors to command modules via Module Manager? I know doing that in the last few versions of kOS could cause ship parts to vanish.

Loading and Quickloading could both cause it to happen (although seemingly randomly). But once it happened to a craft, that craft was stuck that way no matter however you loaded it from that point on, until you roll back to kOS v0.13.1 at which point the afflicted craft would be whole again.

Here's some behavior notes the screenshot alone may not capture: This is on OSX (I don't know if it's platform specific). Duplicates don't seem to function properly when clicked. Duplicates only exist when controlling an active craft. They go away at the screen of the space center buildings. But upon returning to a craft, will reappear. When duplicates happen, the windows associated with those buttons (FAR/KER) tend to reset to default window positions (center of screen). Restarting the game fixes it. I'd like to offer a log of this happening, but of course now that I want it to reproduce it, it's decided to be uncooperative. Given some time it's bound to reoccur, as I've seen it happen too many times.

Has anyone ever noticed duplicate (or even triplicate) application-launcher buttons being created?

Yup, happens with a regular load (from KSC screen) or quickload. And it happens even if the kOS Processor is NOT the root part, and happens without adding kOS processors to command modules. My command module is my root part and I don't add kOS processors to them with MM (at least not since v0.12). Also, I do not use RT2, so this is likely not an RT2 integration issue. Reddit user "NPShabuShabu" said he had submitted a commit that would fix it.

AstroTrain might disagree.

Maybe you guys are already aware, but just in case you aren't I thought I'd note a problem I had with kOS v0.14 causing my craft's parts to go missing. I've rolled back to v0.13.1 for the time being, and my damaged crafts are intact again, but boy, was that a scary bug.

I'm experiencing a bug with pWings: I can pick a wing-part up, but when I place it on my craft, it doesn't actually attach (despite making a sound as though it did). The debug log is spammed with Null Reference Exceptions, and shortly later a crash will occur. I saw the above comments implicating NEAR, but I don't use NEAR, I have FAR. (I'm not certain if that should make a difference). My Player.log is here.

I can see both sides of this issue. While I'd like the convenience of kOS figuring out average ISP automatically, implementing it on one's own really isn't THAT many lines of code. And it typically doesn't need to be done more than once per script. Once I get my version to accommodate thrust-limiters, I think the code is going to be pretty darn reusable. Also, it's worth noting some mods have funky engines, like the DT Vista Fusion engine in Interstellar, which has variable ISP depending on the throttle. A built-in SHIP:ISP property could lead to misplaced trust in bad values in those weird situations.

Oh, so you were doing a burn-time script. Well just in case you want a bit more to help toward that end, I have a script I use for automating all my maneuver-node burns: http://pastebin.com/8HhaHYfg I've actually made some recent adjustments that would make it take thrust-limiters into account, but I haven't had a chance to test if that feature actually works yet, so I'm holding on to that version for now.

The last version of kOS that I know tolerated using MM to add kOS Processors to command modules was kOS 0.11. After kOS 0.12, that hasn't been an option. Parts of ships go missing, and bad things happen.

I'm not sure about the ∆v, but you can get your engines as a list, and loop through them to get ISPs. If all the engines are the same, your average-ISP is the same as an individual engine's ISP, but for engines that are different, you need to calculate that yourself. To see how to calculate your average ISP on paper, see this tutorial. For a kOS example of how to calculate average-ISP among different engines, try this: set sum to 0. LIST ENGINES in MyEngines. for engine in MyEngines { if engine:ISP > 0 { set sum to sum + (engine:MAXTHRUST / engine:ISP). } } set ispavg to ( SHIP:MAXTHRUST / sum ). I'm not sure if this works in-atmospheres, as I only tested this in orbit, but I can confirm it seems to work there, at last sufficiently enough to accurately calculate burn-times.

I personally don't mind the simplistic textures. They look clean but more importantly, they save RAM.

Oh wow, that newer foot is much nicer. Good work. Do you think they'll have better-than-usual impact-tolerance? I'd be worried about breaking them, especially since (assumably) they wouldn't be repairable in-situ like stock landing gear and wheels.

When you described this as a "quad leg" I thought to myself that nobody can use those things as legs given the narrow radius, but then based on how you describe it being in a foldatron (like the wheels), it sounds like this part wouldn't be as much a "leg" as it would be a "foot" (with quad toes). From that angle, I like it. Along with foldatrons it would let you build some very customizable landing legs. Just be sure to give them slightly better crash-tolerance versus most parts.

@Helix935: I actually did allow the centrifuge to fully inflate before attempting any crew transfers. @StarWaster: I searched the thread for animation discussions and found what you were alluding to. It seems to have fixed the issue. There's now a minor issues where CrewXfer now thinks there's 2 of each person in the module and offers 2 transfer-buttons per name, but it seems to be benign. Thanks.

I'm having some trouble with my centrifuge. It seems CrewXfer can't transfer crew into the centrifuge. Any ideas for a solution?

Thanks for making these rework parts, they appear to use a lot less RAM than the legacy ones.

I made a series of illustrated tutorials for orbital rendezvous & docking. There are 4 techniques. For a link to all the images in a single imgur album, click here. Hohmann Transfer Rendezvous: Orbit Phasing Rendezvous (easy radial-burn version): Orbit Phasing Rendezvous (more efficient prograde-burn version): Parallel Orbit Rendezvous: Changes: v7 - Adjusted phrasing in one chart and updated drawing of spacecraft in all 4 charts. v6 - Fixed a typo in the Hohmann transfer's step 6. v5 - Added 2 techniques (for a total of 4). v4 - Spelling error corrected. v3 - Refined instructions for final approach, docking indicators now also includes Navball Docking Alignment Indicator, more notes on how to be efficient. v2 - Split into 2 versions: efficient & easy. v1 - Original version.

As I understand it, that's just for old B9 crafts to work.

Actually this install isn't using any new B9 5.0 stuff, it's all old B9.

This is mine: But again, the crashing is only on scene-changes, like when you have the black loading screen between the VAB and launchpad. edit: and until today, I also had Interstellar in there too.

I've already got ATM. I was hoping B9 would eventually become smaller memory-wise, but if not, it looks like I may have to learn to eventually live without it to avoid semi-frequent crashing (although only on scene-changes, which is weird). I've bent over backwards to avoid this (even deleted Interstellar), but it's such a big mod it makes it difficult justify not-pruning.