dewin

Along these tangents, I've posted a suggestion for better addon management recently, which includes the notion of each mod having a "manifest" of sorts including its name, version, KSP-compatible version, license and some other metadata. This'd solve the version issue -- really, if a user wants to try to run an outdated mod they should be allowed to do so but it should be made clear that they shouldn't expect it to work.

Has anyone experienced this issue without doing doing a deployment like this? I'm not the plugin author (nor have I poked at the source), but I practically have a 100% "breaks games until next reload" test case of build comsat as subassembly, build multi-satellite carrier craft, attach comsats in symmetry, deploy 1-2 satellites successfully, crash somewhere around the third or fourth deployment when changing ships. The one common link I can think of is that the satellites all have the same origin vessel and have been renamed. (In fact, one crash was while cycling between them to change them from "Kerbin Comsat Launcher Probe" to "Kerbin Comsat E1" etc. The crash only seems to be on scene change, so cycling with '[' and ']' doesn't trigger it (nor switching from the map if the target is in physics range)

To truly do this well, I think each body would need music for a few themes, though some of these can probably be shared between similar bodies: Arrival (entering its SOI) Orbiting Landing (suborbital trajectory, low altitude, descending) -- possibly a little tense to fit the "can't mess up the suicide burn" feeling if that's how you're landing. Landed (possibly separate day and night themes) Taking off (as per landing but ascending) -- less tense, more "Whee let's blast off into space" exciting Also something for Kerbol orbits, which might also kick in if you're on an escape trajectory and are pretty close to the edge of SOI already.

Nope. The option you're thinking simply adjusts start and end altitudes for the gravity turn based on the body you're on.

If your rover is "slightly beyond Minmus", it's out of KSC's range without some relays.

I've experienced this issue even without MJ -- RT2's flight computer failed to do any sort of turning towards the maneuver node I created (or any other turn direction e.g. Prograde). The satellite had an active communications link, power, etc. What ultimately ended up fixing it was cycling between crafts a few times -- note that more than one craft was in the scene at the time (the satellite + my multiple satellite deployment vehicle which it had just undocked from)

I like this so far, but here's some feedback: 1. This doesn't seem to play particularly well when multiple versions of the same mod are available (e.g. Mechjeb's dev and stable builds): When I hit the "All Mods" button, it helpfully extracts all the files in Mechjeb... and then deletes them when it reaches the other version in the list. I can work around it a little but -- if you changed it to process all deletions first, and then extractions -- it'd avert this problem. 2. It'd be nice if I could "ban" certain files, e.g. "Don't ever install anything named ModuleManager.dll or ModuleManager_1_5.dll, because I have ModuleManager_1_5_6.dll already". 3. Likewise, it'd be nice if I could manually change the order mods are processed in (I use the common toolbar mod, and I want to ensure the latest version of it that I downloaded myself takes precedence over any outdated versions that might be bundled with other mods. 4. Could you remove the leading backslash on the paths when choosing a destination, so that I can just hit "G" to target \Gamedata instead of having to manually select it from the list? 5. If KSP is installed on an NTFS partition (extremely likely), it's possible to create multiple KSP installs without requiring (much) additional disk space usage using junctions and links. I wrote a guide on doing this for WoW back when I played it, and it'd be handy to have the ability to do something similar in an automated fashion in KSP.

Many many muns ago when I was growing up, I had imaginary companies that made sci-fi tech, so I've reused some of them: Merklin Enterprises (which is Merklin Heavy Industries in KSP, because I was planning on messing with Kethane on that save) and Next Phase Incorporated (which is Next Phase Incorporated on one save, Next Phase Technologies on another) The save I made solely for KSP Reddit challenges is "Bad Idea Factory", though I've to date only bothered to complete one challenge (#12, though it technically completes several others) and have yet to post it --> http://imgur.com/a/6lZSW

This is a series of suggestions with the idea of having better support for addons. The end goals are: Allow addons to be enabled or disabled per-save Allow addon configuration to be per-save and solve the "multiple installs required for multiple addon setups" dilemma See metadata of all installed addons (whether enabled or disabled) at-a-glance (author, license, version, etc) Allow addons to declare dependencies/optional dependencies on other addons Some of it is loosely based on the addon support in WoW (mainly the concept of addons having a manifest of sorts and an interface for selecting/deselecting them for load). Also it's probably a fairly significant overhaul, but I'm crossing my fingers for it someday (distant future?) anyways , even if a stripped-down version. Part 1: Addon Manifest File This is a small per-addon file that lives in its root directory (e.g. Gamedata/Addon/manifest.cfg) that provides the following information: Name of the add-on (required) Short description Author License (required) URL Addon version Supported KSP version (required) Required dependencies (must be loaded before this addon loads), optional dependencies (load before this addon loads if they are available), and Incompatible With (advisory "Hey, these two addons don't work together" option). Optional metadata This manifest file enables an at-a-glance view of all installed addons, their versions, and whether they're compatible with the current version of KSP. It also opens up the possibility of an addon updater -- either official or third-party. The "Optional metadata" section is intended primarily for future third-party use -- e.g. perhaps in conjunction with one of said addon updaters. Requiring the "License" field helps maintain the current forum requirements of no downloads without a license. It might simply be "GPLv3" or "CC-BY-SA" or can be as complicated as "See included license.txt file" Part 2: The glue that makes it all work Skip loading all addon information (DLLs, part configs, etc) when starting KSP, except for manifests. The list of enabled addons is saved per game. When starting a new game, have a new "Addons" button which opens a list of all installed addons and allows them to be enabled/disabled individually for that game. Clicking on an addon shows the author/title/description/license/URL. Clicking the URL opens that website (probably Kerbal Space Port or a forum thread here) in the default browser. If the addon has a 'license.txt' file in the root, clicking on the license displays it. Addons that are out-of-date (wrong KSP version in manifest), are missing a license, or are missing a required dependency can all be denoted here. (If there's a minor bugfix update to KSP, it can still consider addons prior to the bugfix update as "current"). If two addons are both enabled and either lists the other as incompatible, this should also be indicated. Users should still be able to try to enable any addon that fails any of these requirements ("So this part pack hasn't been updated in 6 months but still works fine and I want to use it"). Addons lacking a manifest file entirely (e.g. any addon prior to this system being introduced) are also considered out-of-date. At the "Resume Saved" screen, have the option to view/adjust the list of addons that game is using. If any addons it uses are not available or out-of-date, warn the user before starting the game. When actually starting the game, load all enabled addons, etc., and such. This means that the normal loading time when starting KSP is mostly offloaded to when loading a game. Since addons are per-game, actions like quickload, revert, etc. shouldn't require a full loading phase and should take roughly the same amount of time as they do now.

Kerbin can be covered with 3 satellites (I did 4) excluding the poles. Here's how I did it fairly easily with Mechjeb and Flight Engineer -- but really all's you need is some way of determining orbital periods. Satellite Design In addition to basic requirements, each satellite needs a minimum of two dishes (to link with with the "previous" and "next" satellites in the orbit), a means of communicating with KSC or your existing network, and probably a means of communicating with other craft. My satellites have 4 dishes (pointed at: Previous Satellite, Next Satellite, Active Vessel, "future use") and two antennas (reaches KSC, really only need one) Launcher/Deployment Vessel Design I built a single craft that carries multiple satellites. Mine carried 6, but I only used 4. I made it manned, primarily so I can control it when on the wrong side of Kerbin in the process of getting the network set up. Instructions 1. Choose target altitude "A". Calculate the following: "P" - Orbital period of circular orbit at this altitude "n" - Number of satellites desired (minimum of 3, more if your network is for some reason low altitude.) "t" - Orbital period divided by number of satellites. (P/n) For the rest of this, I assume Kerbisynchronous orbit at A=853,206.67 km with an orbital period P=6 hours, n=4 satellites, and t=4.5 hours. Adjust if you use different numbers 2. Launch into an orbit with an apoapsis of "A". Adjust periapsis so your orbital period is either P-t (4.5 hours) or just "t" (1.5 hours; may not be possible in synchronous orbit) 3. Ensure all of your antennas are configured in such a way that your satellites will be able to reach KSC when they have line of sight to it. Have one dish per satellite pointed at "Active Vessel", at least for now. 4. While in range of KSC/your satellite network and on the "upward" (reached periapsis, en route to apoapsis) part of your orbit, undock/decouple your first satellite. Set the satellite to circularize at its next apoapsis. The satellite's orbital period should be "P" (6 hours) when you're done, you might use RCS to fine tune depending on how picky you are. It's not necessary to have a perfectly circular orbit, as long as it's relatively close and the orbital period is correct. Timewarp/etc until your first satellite is positioned correctly. Switch back to your launcher vessel. 5. By now, your launcher should either be nearing its apoapsis (or just passed it). On satellite #2, point a dish at satellite #1 before undocking, then repeat step 4. Satellite #2 should have an uplink to satellite #1 by the time it reaches Apoapsis, and due to the orbit timings it will be exactly 1.5 hours "behind" or 1.5 hours "ahead". If satellite #2 doesn't have LOS to #1, you either warped too many orbits or your target altitude is too low. 6. Repeat steps 4&5, always pointing one dish of the new satellite at the previous satellite to be deployed. 7. When your launch your final satellite, connect the additional dish back to the first one. You should have links that look like #1 <-> #2 <-> #3 <-> #4 <-> #1. Note if you're doing 4 satellites like I did, #1 and #3 will never have direct LOS to each other so there's no need to link them -- same for #2 and #4. Notes 1. Kerbisynchronous orbit is not required, but is helpful. The drawback of not doing it will be that your first satellite won't have 100% LOS to Kerbal Space Center, so your subsequent satellites might lose uplink during the positioning process. If you're clever enough with timings or your launcher vessel can control (6 crew + whatever the special dish for it is), that is a nonissue. 2. If you don't want to fuss with Molniya orbits, you can do this exact same process with a polar orbit once your equatorial network is functional. The catch will be that -- while your polar network will always have LOS to your equatorial network, you can't determine which satellite in it they'll be able to reach, and they may not be able to reach KSC. Solving this is an exercise for the reader. 3. Other orbital periods for step 2 work as well, either P*x+t or P*x-t for any integer value "t" >= 0. The goal is that every orbit of the deployment vessel has it either "x" hours/etc either "behind" or "in front of" the last deployed satellite while at apoapsis. 4. You can also get away with swapping "apoapsis" and "periapsis" all of the above instructions. It takes more time to get set up, but works and is a must if you want something like... a communications network of satellites in say a 30km orbit For a link to happen, both ends of the link must be within transmission range. It doesn't matter how much power your transmit with if your recipient is using a walkie-talkie. A dish can't communicate with multiple sources at the same time IIRC (not sure for the "pointed at a celestial" case), so your deep space ship needs a second radio for the relay to whatever it's sending to. The second vessel only needs to be able to reach the spaceship though and does not need to independantly be able to reach all the way back.

I'm having a similar issue with the same two addons (admittedly, with about 20 others as well), and there's error log spam about being unable to find the active vessel or having an invalid active vessel that multiple plugins would complain about. I'm also having an issue with rapid unplanned disassembly when switching vessels sometimes, but I'm currently suspecting FAR or KJR for that one.

I admittedly run a plugin-heavy install, but I'm having a problem that I think is this mod. I recently added RemoteTech 2, KJR and FAR to my list of addons -- all the most recent (and 0.23 compatible) versions. I'm sporadically having two problems when I switch craft (and occasionally when recovering a craft and returning to the space center -- so any scene changes). Neither of these problems occured prior: The first is: When changing vessels, there's a chance I'll get some interesting camera shaking, paired with random unplanned disassembly. Reloading my last quicksave and switching vessels does NOT trigger this. I suspect the camera shake hints that something is causing the COM to be in the wrong place (since the camera centers on COM normally), but whether that's the cause or a symptom is impossible to guess. The second is: When changing vessels, I'll occasionally get the "stuck at 0 meters" altitude bug with LOTS of exception spam about being unable to find the active vessel (I don't have it handy at the moment). This leaves the game broken until I full out restart it (I can return to the space center which is also broken; exiting to the main menu and resuming my save won't fix it -- but restarting the game entirely and resuming my save is fine). RemoteTech 2 was having an issue like this prior to its 0.23 update so I'm more inclined to blame it, but I'm mentioning it here in case it's helpful. Currently running the following (long) list of plugins -- I can try to narrow it down later when I have more time: The common Toolbar plugin blizzy's Achievements plugin ActionGroupManager EditorExtensions Engineer Module Manager 1.5.6 KJR FAR KAS KerbPaint Kethane MechJeb2 ProceduralFairings chatterer KSP Interstellar SCANsat SelectRoot TacFuelBalancer TreeLoader KerbalAlarmClock various parts modules which do not add plugins and thus aren't likely culprits (KW Rocketry, etc.)

This determines how orbits (and predicted orbits via maneuver nodes) are drawn, notably in cases where you're changing between SOI. I don't know exactly how they all work, but the two I use most common are 0 and 3 (the default): 3 gives you one continuous line -- that is, the displayed orbit is always relative to the reference frame of the current SOI. 0 relative to the SOI they're in. This is particularly handy when doing transfers -- if you're going from Kerbin to the Mun, you can double-click to focus the Mun and then zoom in to get a better look at the situation/better place maneuver nodes. It's near essential if doing anything like an interplanetary transfer. You don't actually need a mod installed to change conics mode (though you do if you want to do it on-the-fly), you can edit CONIC_PATCH_DRAW_MODE in KSP\settings.cfg. Also handy to increase is CONIC_PATCH_LIMIT (probably to 5 or so), which determines the number of predicted orbits that will be displayed. For instance, if you're launching from Kerbin and slingshotting by the Mun to transfer to another planet, it'd look something like this: Conic #1: Your current Hohmann transfer trajectory from Kerbin to the Mun Conic #2: The Mun flyby trajectory. (In mode 0, you'll see this as your first line abruptly ending and then another line where Mun currently is, rather than where it will be when you arrive), Mode 3 has it relative to Kerbin's) Conic #3: Back in Kerbin's SOI after Mun escape, en route to Kerbin escape. Conic #4: Kerbol orbit Conic #5: Your destination planet's orbit. HTH.

This gives me a better idea for refining this as a feature request: * In the VAB/SPH, show the altitude ranges in the 'extended' part description area (the new 'what-you-see-if-you-right-click' section in 0.23). * Have the same information show on the LO/HI/BIO/etc indicators on the small map upon mouseover, which makes it easy to check in flight. (You can use the color-coding to know if it's good or not, but if it's not there's no hint as to what direction you need to go to fix it).

It indeed doesn't work outside the min/max altitude. The window will show the text in orange instead of green when this is the case. I suspect 'optimal' is the altitude where your scan covers the widest area -- and if you scan with a satellite in an eccentric orbit you'll get a good view of this.

Any chance that the min/max/optimal scan ranges can be made visible in the VAB/SPH? I know we can look at the .part files, but having it integrated in the game would be nice. Loving this mod.