Starstrider42

I believe Kethane also has its own water expansion, separate from MKS.

Everything in KSP.log is also in KSP_Data/output_log.txt. Please do not send the RT2 team (or any other mod developers, for that matter) KSP.log; it's much less informative for bugfixing.

It's in the KSP_Data folder in your KSP folder.

Please post to https://github.com/Cilph/RemoteTech2/issues, following the bug report guidelines, including an output_log.txt. Knowing there's a bug around is handy, but knowing when it does and doesn't happen is much better. Thanks! EDIT: Possible duplicate issues are https://github.com/Cilph/RemoteTech2/issues/217, https://github.com/Cilph/RemoteTech2/issues/187. Did you see any terrain problems in your case?

This is a request to improve the KSP API. Just like there's a flag "KSPAddon.Startup.EditorAny", which allows a plugin to be loaded in either the VAB or the SPH, it would be nice if there were a flag "KSPAddon.Startup.RealTime", which would cover scenes in which the game time progresses. At present, there are three such scenes: SpaceCentre, TrackingStation, and Flight. I assume the much-discussed mission control center would also fall under this flag, once implemented. This would greatly streamline developing plugins that need to keep an eye on the game state.

Try opening your persistent.sfs file in a text editor (after BACKING IT UP of course), doing a search for "Kz", and deleting any references found in Tech{} nodes. That should reset the relevant parts of the tech tree. e-dog, you might want to look at RealChutes. They did a similar upgrade from many-sized to procedural parts, and aside from having to delete the "legacy parts" folder in each new install, I'd say it went rather smoothly. EDIT: dumbel, I just thought of a slightly easier workaround: try copying Ships/ from your save file to a new sandbox game, editing the parts in the VAB there (where you should have no tech restrictions), then copying back. Still lots of manual editing, but you only need one pass per ship instead of two.

You can. KerbMav's method works for any tracked asteroid, whether or not you've docked to it.

What about the stock biome scanner? 24 == 16 | 8 MODULE { name = SCANsat sensorType = 24 fov = 4 min_alt = 5000 max_alt = 500000 best_alt = 250000 power = 1.5 scanName = multispectral scan animationName = Multi_Antenna }

I have to disagree. Biome and anomaly scanning are fundamentally different, and one might want to make a part that does one but not the other. So those should be kept separate. Second the idea of making BTDT a fundamentally different component, though. The way it works right now is a bit unintuitive.

http://wiki.kerbalspaceprogram.com/wiki/RC-L01_Remote_Guidance_Unit Sorry, don't know about that one.

Thanks for your quick response. One more feature request: When 0.24 comes out, there will likely be a transition period when I'm supporting both 0.23.5- and 0.24-compatible versions. Can there be a way to say "version X is the latest for 0.23.5, but version Y is the latest for 0.24"? That way people who are delaying upgrading to 0.24 won't get an (incorrect) warning about not having version Y.

One suggestion and one question: Suggestion: could you please make it so that the log messages say which file is being parsed? It's hard to find problems (or even to know if they're in your file or somebody else's) otherwise. Question: how do you indicate that a mod is compatible with, say, both KSP 0.23.0 and KSP 0.23.5? Thanks!

I've found, and fixed, a serious bug that came up when undocking a ship from an asteroid. Fixed version is in the first post. In other news, I'm hoping to have version 1.0 out next weekend. At that point, I'll be moving CA to the Add-On Releases forum.

No, recyclers don't store anything. You can leave them in place.

https://github.com/Anatid/XML-Documentation-for-the-KSP-API The documentation is a bit patchy (and science, unfortunately, isn't covered yet), but it's still quite helpful.

I'm pretty sure v_peri = sqrt(μ/a) × sqrt((1+e)/(1-e)) applies even to a hyperbolic orbit. So then the delta-V needed is sqrt(μ/a) × [sqrt((1+e)/(1-e)) - sqrt(1/(1-e))].

Thanks for the detailed post, it's much clearer than the original MM instructions. However, do you think you could define (possibly with examples) what you mean by patch and node? This part is pretty confusing to me, and I imagine it would be worse for people who are just starting with MM and aren't familiar with the file structure.

Both Vasious's original post and the edited version did have lat and long. I removed them because they seemed concerned about spoilers. Vasious, I'm afraid I've run out of advice on the subject. Sorry I couldn't be of more help.

Not sure I understand the vertical lines on the plot, but yes, it does sound good.

It would be a lot easier to tell with indentation, but it looks like you're missing some braces and all the STATION tags: GroundStations { STATION { Guid = 5105f5a9-d628-41c6-ad4b-21154e8fc488 Name = Mission Control A ... Antennas { ANTENNA { Omni = 7.5E+07 } } <-- ADD THIS HERE } STATION <-- ADD THIS HERE { Guid = 5105f5a9-d628-41c6-ad4b-21154e8fc487 Name = Mission Control B ... Antennas { ANTENNA { Omni = 7.5E+07 } } } STATION <-- ADD THIS HERE { Guid = 5105f5a9-d628-41c6-ad4b-21154e8fc486 Name = Mission Control C ... Antennas { ANTENNA { Omni = 7.5E+07 } } } }

And the relationship between the two DOES depend on altitude. To answer the OP, you'll need to experiment with the maneuver planner in map view. The new mode that lets you see the trajectory relative to the focused planet helps a lot with this. If, for example, you want the biggest outward boost, you want to adjust your flyby altitude until your post-flyby trajectory, relative to the planet, is parallel to the planet's orbit. Coming in higher or lower will both give you a lower apoapsis around the sun.

I haven't had a chance to try out the new version yet, but does MA support (or can it be made to support, if it doesn't yet) loading asteroids from a save file and including them as destinations?

No need, I was just asking out of curiosity.

So does this mean all planets with atmosphere have auroras? I guess there's no consensus on which planets do or don't have a magnetic field...

I assume that config nodes with spaces in their names are also a big no-no where MM is concerned?