toadicus

That definitely shouldn't be happening. Can you get me a log (Windows: \path\to\KSP_win\KSP_Data\output_log.txt; Linux: ~/.config/unity3d/Squad/Kerbal\ Space\ Program/Player.log; Mac: ~/Library/Logs/Unity/Player.log)?

Technically speaking, that "210 m/s" is incorrect for an optimum return from Mun. It's only correct that you need 210 m/s to escape Mun's influence; you need a bit of additional delta-V to push your periapsis back down to Kerbin's atmosphere. The key to minimizing a Munar return is in making sure you burn in the correct place. You want to place your escape burn from the Mun such that your orbital velocity is going to naturally put you into a Kerbin orbit with a lower periapsis. For an equatorial Munar orbit, that location is typically about 10-30° counterclockwise from the Mun's "prograde" orbital vector, IIRC. The cheat sheet doesn't really have a good way to estimate that, but the very cheapest I've ever made that burn is something like 232 m/s. Edit: The more I think about it, the less sure I am about that number; it might be more like 320 m/s? It's been too long.

No problem man; I always appreciate your input.

I just checked the version archives and it looks like Engineer.Extensions.dll has been unnecessary since 0.13. 0.12.* and previous depend on it. You're welcome! Glad to hear initial good reports; hope the bug is thoroughly squashed.

Just FYI folks, the archives have been updated with a version of 1.4 recompiled against a changed ToadicusTools library. If you're updating VOID or AntennaRange today, you should re-download TweakableEverything as well. LostOblivion, I'll try to get a test install for that set up later today. I'm going to guess it's a fight between TweakableFairings and ProceduralFairings, both of which want to manipulate the autoshrouds on engines.

AntennaRange has been updated to version 1.4.1! This minor update primarily addresses some changes to ToadicusTools, but also introduces support for the ApplicationLauncher as a fallback when the Toolbar mod is not installed. Also, there's a small bugfix. INSTALLATION NOTE: ModuleDB.dll is deprecated and should be manually removed once all of my mods have been updated on your system. CHANGELOG: v.1.4.1 [2014-08-16] * Added support for Squad's ApplicationLauncher. This will be used only as a fallback when the Toolbar mod is not present. * Improved null detection to resolve some issues with controls locking in certain scenarios. * Updated ToadicusTools.

VOID has been updated to version 0.14.1! The only changes in this release are tied to how VOID and ToadicusTools interface with KER, and deprecates my ModuleDB, which wasn't really providing the speedup I thought it would. Hopefully this will fix the crashes around staging, launching, recovering, etc. If you use any of my other mods, you should probably update them as well in case the changes to ToadicusTools don't play nicely with them. INSTALLATION NOTE: ModuleDB.dll is deprecated and should be manually removed once all of my mods have been updated on your system. CHANGELOG: v.0.14.1 [2014-08-16] * Updated KER code, and VOID's methods of integrating with KER. * Updated ToadicusTools.

I've made a bit of progress independently last night, and am talking with padishar today; I'm slammed at work and won't be able to code here today, but hopefully we'll find a resolution this weekend.

With apologies to the moderation staff for double posting, TweakableEverything has been updated to version 1.4! This version adds a new TweakableIntakes module and improves a few annoying but situational problems from past versions. CHANGELOG: v.1.4 [2014-08-13] * NEW MODULE TweakableIntakes allows for the closing and opening of intakes in the editor, and adds action group items for open and close intake. * TweakableEVA: Cleaned up the exception reporting a bit so hopefully fewer people will think it's a bug. * Various: Improved/added null checking to cause problems in even fewer unanticipated scenarios. For those hoping this fixes the missing TweakableDockingNode functionality: I hope so too! Please let me know, and provide logs if not.

Welcome! AntennaRange does not require transmission to any specific point on Kerbin: a signal that gets to Kerbin is good enough. I summarized my thoughts on this quite a while ago, and my feelings still stand. So, that's not a bug, it's a feature! If you can talk to Kerbin from the far side of the Mun, we've got a problem.

Ah-ha! I can't be 100% sure, but I've a good hunch I know what's going on. ToadicusTools is shared amongst all of my mods, and the most recent version of VOID made some changes to it. Whenever I update a mod, I repackage all of the old ones with the new version of ToadicusTools. Were I to guess, something's just wrong enough that KSP won't load the classes that depend on it. I've had an update half-ready for a couple of weeks; trying to polish it up now. A recompile on my end should be all that's needed to fix your issue, but I may as well get some new content out while I'm at it.

Thanks! That VOID_HUDAdvanced log entry is not actually a problem: it's a handled exception that I couldn't clean up any other way. For reasons which escape me, VOID_HUDAdvanced winds up changing GUILayout things in a way that Unity does not expect, in the very first frame of a flight scene. None of the other modules have the issue -- VOID_HUD doesn't have the issue, and the modules are fundamentally identical -- so for want of a solution I'm just catching the Exception and letting everybody go about their business. It doesn't interrupt anything (except that first frame of VOID_HUDAdvanced), and unless Unity or KSP have some really, really funny ideas about Exception handling, basically could not be responsible for the crashing. If you ask around, everyone, everywhere with VOID installed will get that message when they open up a flight. I'm not going to say VOID or the KER code can't be implicated in your crashes, but considering what VOID/KER do (GUI elements) and how they do it (maths), the odds seem pretty low. That said, I'm very interested to hear where your investigation leads.

Yes it does! The TweakableDecouplers module will add tweakable sliders to the right-click context menu for all of your decouplers.

Once again: it works fine for me. I've checked the download archive and I don't see anything wrong there that's since been fixed on my end. Do you have all of TweakableEverything installed? TweakableDockingNode depends on TweakableStaging. Do you have exactly one version of ModuleManager installed? Is there anything else relevant you can tell me? Have you provided me with a debug log (Windows: \path\to\KSP_win\KSP_Data\output_log.txt; Linux: ~/.config/unity3d/Squad/Kerbal\ Space\ Program/Player.log; Mac: ~/Library/Logs/Unity/Player.log)? I'm happy to admit that there's a problem, but so far I haven't got enough information to identify it. "It's broken" only helps me fix it if it's broken for me too.

Hmm, I need to think about this. In general I agree with Squad/FAR/whoever made those tweaks that as-is they belong in the editor. But, restricting them in flight could make sense and in the example you describe I'm guessing modern control systems would do something similar to help keep things controllable. What if I made an in-flight control range "throttle" that let you lower the value, but not raise it? So, the value you set in the editor would essentially be the "max" value. If you need your max value on the return trip instead of the departure, you tweak it down on the runway. Otherwise, you tweak it down on the way back as you describe. The big downside to this is that there's no action-group-able way to operate tweakables, and in flight they don't apply symmetrically, so if you've got half a dozen sets of control surfaces you're going to be clicking and adjusting up to a dozen times. I've occasionally decided against things just because using the tweakables would often be overly laborious.

You're welcome! Thanks for helping me make it better. So, I've finally had a chance to sit down and look at this. Unfortunately the news isn't great; there's nothing obvious going on here. The Exception there is the result of a race condition; in large, heavily-modded saves when load times are very long, Unity starts firing FixedUpdate events before everything is started up. ARFlightController is in charge of changing the icon color and locking the controls; it's trying to do its thing but the ModuleLimitedDataTransmitter in your antenna isn't set up yet, and chokes. I'm not entirely sure that's causing the issue you're having... but it might be. So, I've added a null check to CanTransmit, which should allow that process to run as anticipated. This dll has that change, and is compiled with debug logging enabled, so it'll make tons and tons of noise in your game and log. Give it a shot; if it fixes the issue let me know and I'll push the fix into a release. If it doesn't, get me the resulting log; maybe it'll have more info for me.

So, there's a lot going on in that log; enough that I'd need to sit down and spend a bit of time studying it to comment on what's really going on. What I can tell you is that you've got some mods somewhere causing some Big Kerfuffles. There are exceptions during startup, the usual OmgExceptionSpam from E.V.E., and then a bunch more about docking nodes and mechjeb and even TweakableDockingNode making noise from then on, which at the very least implies you've got a mod somewhere doing something that TweakableEverything does not expect (or stopping something that TweakableEverything expects to happen first). The AntennaRange exception you got, I suspect, is actually not related to your problem at all. It only fires once, and it's during a ship load/unload or vessel switch; it's probably a race condition of some kind and generally harmless. That said, you definitely do have an issue during FixedUpdate runs that is preventing AntennaRange's "do I have control?" check from running. There are complaints from EnhancedNavball and Clouds in particular, but I use both of those and don't have this problem so your issue probably lies elsewhere. I don't have time right now to build an install to load up your persistence file, but if I do over the weekend I'll let you know what I see. In the meantime, though, I'm going to reiterate my suggestion that you look elsewhere for your solution; I don't think AntennaRange is causing it.

Same here. The shielded docking port doesn't seem to have a toggle action. Hmm, it works fine on my install. Do you have anything else installed that might be conflicting, or a log that I can check to look for issues?

VOID has been updated to version 0.14! This is the "quality of life" update I hoped to release before my holiday but didn't. It includes a new Career Status module, fixes to the HUD skin and window resizing, and updated vessel simulation code. This does not have any changes to the CSV logger. I'll try to work on that before too long. v.0.14 [2014-08-03] * NEW MODULE! VOID_CareerStatus is a nascent module that displays a few vital Career Mode statistics: Funds, Reputation, and Science, including the most change (that happened during this flight session). * VOID_VesselInfo: Resource mass no longer a combo line. * VOID_HUD/AdvancedHUD: Fixed an issue where certain changes in the game and other mods would cause the HUD skin to change. * Now supporting the application launcher with a new button that will be used in lieu of the old standalone button when the Toolbar mod is not present or VOID's Toolbar support is disabled. * Fixed an issue where modules with "extended" toggles would not reset to their condensed size when the extended data was toggled off. * Miscellaneous code "improvements." * Updated underlying VesselSimulator code to the latest from KER & padishar.

"Fixed". I haven't looked into it in depth since 0.24.1 was released, but based on mecki's report I feel very confident in my answer. At any rate, since the issue happens after AntennaRange is no longer installed, it is certainly not something I can hope to fix, unless ModuleManager can address it.

I would bet money that's to do with KSP's new PartLoader system. AntennaRange replaces Squad's ModuleDataTransmitter on all of the stock antennas (and any others you have patches for, e.g. MeCripp's patch pack), so in your .craft files and save game files, all of your antennas are saved with AntennaRange's ModuleLimitedDataTransmitter in lieu of Squad's ModuleDataTransmitter. Previously, KSP's default behaviour would clone the prefab part and then try to load from persistence, so when you removed mods you'd always get Squad's modules back. That doesn't seem to happen anymore; if there's nothing in persistence, Squad doesn't load a module for it at all. This seems like a major regression but at this point it's not one I can do anything about. So, my advice at this point is: If you're "just trying out" a mod, do it in another KSP installation dedicated to sandboxing and testing. If that's untenable for whatever reason, always back up your saves before installing a mod, so that you can revert to your previously-healthy save if you decide not to use a mod. As a very last resort, scavenge your broken save files and revert changes from mod patches manually. In this case, remove all MODULE { name = ModuleLimitedDataTransmitter // ... } blocks and replace them with MODULE { name = ModuleDataTransmitter } blocks. None of this should be necessary, and it's a big burden on mod users and developers alike. I'll be watching the ModuleManager thread for a while to see if there's anything we can do to ameliorate the situation. So that's fixed it then? Happy to help out.

Any chance the ground station was flagged as Debris? AntennaRange ignores vessels flagged as debris to keep performance up on late saves with bad cases of Kessler syndrome. From the log, which called what I believe to be your ground station "Munrover Debris", I'm guessing it is flagged as debris. Change the vessel type to "base" or "rover" or "probe" or "anything but debris" and you should get a connection through it.

I think that's available in the rendezvous window when you have the other vessel targeted or selected in the Vessel Register. If it's not, I'll find a spot for it. That's the same bug I addressed here; it's fixed internally.

I haven't written configs for any non-stock parts, and AFAIK only MeCripp has published any others: http://forum.kerbalspaceprogram.com/showthread.php?p=1157251#post1157251 If SXT isn't in there, you'd probably need to build one yourself. If you do, be sure to share! ). But the actual rover, with a Comms 16 that is parked right next to it has no connection (http://i.imgur.com/XOAiE3b.png). As per the OP, "if your ship has a short range antenna, but is in range of a longer range antenna that can communicate back to Kerbin, it will do so", but this doesn't appear to be happening. Any ideas/thoughts/suggestions? This is the second time I've done this contract thanks to me forgetting the actual part the first time round, I'm not really in the mood to repeat it a third time.. Is there anything interesting in the log when you're switched to the other vessel? Does it change at all if you change the LOS fudge factor? Does the 16 on the rover say anything like "blocked by the Mun" in its context tip? I'll try to duplicate, but we'll get there faster if you've got more info.

These requests are fairly related and at this point the short answer is that last I looked there's no easy way to work things like that into TE. I will have a read through that thread and have a look at other mods that provide similar functionality and see if it's something that this mod can cover. There's a real possibility that it's not, but I'll let you know once I've dug into the issues a bit.