cgwhite4

MM has updated to 2.8.0. I am still experiencing an issue similar to the one I originally reported to Sarbian, but it is occurring at a slightly later point (the text on the loading bar now says something about parts, and the bar has progressed beyond where it gets before it jumps back to take care of stuff it moves forward from after the loading screen).

Based on what IgorZ said above, it looks like the failure probably occurred at the point when MM would have loaded the first part from either KAS (current or Beta) or EL. Good to see that 2.8.0 is now ready. That should clear the current problem. Edit: Well, it got farther than before, but is still crashing during loading screen. This time, the bar said something about parts, so it looks like what I thought was happening based on IgorZ's comment is what is happening now, not what was happening before (and could be KAS and EL instead of MM). Aside from updating MM to 2.8.0, my mod list has not yet changed.

It looks like KSP 1.3, which just came out, is completely incompatible with MM 2.7.6. I previously observed a report to this effect in the KSP 1.3 thread, indicating that the game was crashing. Upon attempting to start KSP, KSP crashed at the point in the loading screen where the progress bar would jump back to take care of operations that would happen after the loading screen in the absence of MM. Steam auto-updates KSP, so it appears I will be unable to proceed until MM is updated (I need EL to do what I am doing, and EL requires MM). I currently have the following mods: MM 2.7.6, KAS 0.6.2, KAS Beta (0.7.3), EL 5.7.2, and KJR 3.3.2. I did get 2 KAS compatibility warnings before the crash, but I believe MM is a pre-requisite for KAS (it certainly is for EL which requires KAS), and those warnings were expected due to the new KSP version. I had already dismissed both KAS warnings before the crash. Furthermore, KAS Beta is known not to conflict with current KAS: IgorZ created KAS Beta this way, and I had been running both before KSP 1.3 came out. Edit: For clarification, the report of incompatibility is in the KSP 1.3 Grand Discussion thread, not the announcement thread. I found it with the search tool while looking for this thread to check if MM had updated yet.

I was having issues with a vessel intended to launch from my Extraplanetary Launchpads supported base on Pol, land on Laythe, and return to Kerbin. It was based on a similar design that had successfully done a mission from Gilly to Eve and back to Kerbin, but that mission had gotten off the surface of Eve before KSP 1.2 came out. The vessel for the Laythe landing mission was unable to stay on node during the Cis-Laythe Injection (and was even having difficulty with its orbit establishment burn). I began to suspect that wobbly joints were to blame, possibly related to a change made during KSP 1.2 or one of the two minor patches since. Even some tests involving autostruts failed to solve my problem, so I figured this mod was the next thing I should try. After installing KJR 3.3.1 and returning to my base on Pol, I found that my vessel can stay on node better than ever, and I have now successfully performed the Cis-Laythe Injection, which was virtually impossible before. I suspect that my other vessels will now be able to fly straighter than ever before, eliminating any navigation error due to wobble and saving me having to redo several maneuvers due to missing a target (such as a celestial object's Hill Sphere). I also suspect I will have less risk of a Kraken while performing tasks at one of my EL supported bases (which also involve KAS winches). While this mod would have been required for a possible future RSS campaign, I would certainly recommend it even for campaigns in the Kerbol system. This is especially true in cases where a rhino engine is to be used for a 2nd stage or higher (as is typical for my crafts), as I have found that an interstage joint involving a rhino engine is especially prone to wobble.

I concur with Merkov: winch is the correct term in this case. Furthermore, I do not recall noticing any linguistic issues with KAS or KAS Beta.

For future reference, if you try loading a vessel at an EL-supported Launchpad, and it appears nearly horizontal instead of vertical and undergoes Rapid Unscheduled Disassembly, it could indicate that your vessel file has become corrupted. This happened to a rover I was planning to send to Tylo from the Launchpad at my base on Pol. No sooner had I pressed the load button than the vessel appeared on the pad but was nearly horizontal instead of vertical. Rapid Unscheduled Disassembly promptly ensued. Thankfully, I was able to revert to a previous save, determine that the vessel had indeed become corrupted, and re-create it from scratch, overriding the corrupted version. The new version was successfully loaded.

It sounds like you just ran an orbital resource scanner and then turned on the overlay to check for surface resources. By default, the KSP standard ore, which can be converted to fuel, is indicated by magenta whereas metal ore is indicated by silver, so it sounds like you are currently in fuel ore mode. I'm not sure exactly what you mean by "fix". If you want to turn the resource indications off, simply press the "Toggle Overlay" button, which should turn off the magenta color. If you want to switch from fuel ore mode to metal ore mode, then press the button that tells you which resource you are set to (this should turn things silver instead of magenta). If you want to only display the locations where there is a high level of the resource in question, increase the threshold until all of the magenta or silver disappears and then decrease it by one step. You can also change color schemes, but I usually do not mess with that. Also, I have noticed that the overlay will now persist in map mode if you switch between vessels near the target celestial object without going through the tracking station unless you explicitly turn it off from the scanner, go to the tracking station or space center, or exit the game. If none of this describes your problem, and this is instead some new bug that I have not yet encountered (I have not run any resource scans since 5.7.2 came out), I have no idea what to tell you.

My guess is the reason I failed to detect the Build Progress Rate Issue for the drills and ISRU is because I must build a vessel and finalize its build before I fuel it, which would take more than enough time for the system to catch up. Because I always top off all tanks before launching, I would never have a situation where I would return to a base from the tracking station and immediately need to refuel, in which case I probably would have encountered the issue.

Both the Build Progress Rate Issue and the Scrap Metal Storage Issue have persisted into EL 5.7.2, the former confirmed just now by a quick test at my now rarely used base on Mun, the latter by a check of the EL tab in the VAB. I guess I'll have to continue manually overriding the variables before starting builds and accruing junk near my bases (my base on Pol is becoming particularly bad about this as of late) for the time being.

Would have simply edited my previous post, but this is not directed at Acenthyl (or anyone in particular), and is unrelated to the above. After successfully landing on Tylo and putting a station on the surface, I have decided to use rovers similar to those I have on Eve and Duna for the base infrastructure on Tylo, instead of the winch-connected modules I normally use. This is mainly due to the need for retropropulsion pretty much all the way down from the 45km altitude orbit I generally use, which means like for celestial objects with atmospheres (Eve, Duna and Laythe) that I will not be able to achieve the precision needed to rely on the winch-connected modules. Two of these rovers should be deployed relatively soon (and will be attached to each other upon arrival at their destination), so I should have some more test data for the new connection system at that point. Edit: It may take longer than I thought: I am having difficulty with landing the rovers. I have side-mounted two boosters onto the first rover for use in the final descent, but the truss decoupler does not put them far enough away to clear the rover's drills. I have a tried a couple things to get them farther away, but each time they end up snapping off during the earliest portion of the de-orbit burn, when the rocket responsible for the bulk of the deployment process still has its booster rockets attached (it is being sent from my Extraplanetary Launchpads supported base on Pol). I am trying to figure out how to strengthen the connection so that it will survive until the boosters burn out and are jettisoned, at which point there will only be the force from 1 mammoth engine instead of 7 to deal with. Until I get it right, I will not be able to safely deploy the rovers: Tylo's gravity is strong enough that landing them with a rocket underneath and then trying to release them from on top of the rocket would likely result in significant damage, if not Rapid Unscheduled Disassembly. Edit #2: Managed to reinforce the connection with autostruts, and get the first 2 rovers down safely. They are now attached to each other. So far, no anomalies.

Unfortunately, the trajectory I had placed this piece of junk in had a "Kerbal perigee" of about 40km. Due to the 200m physics calculation range, I therefore needed to "ride it in" in order to bring the piece the rest of the way down via aerobraking. Switching away from a piece that is in the process of aerobraking is not allowed (the game would revert me to before the aerobraking had started), and only one aerobraking pass was required to bring the piece down. Had I lowered the Kerbal perigee of the junk in question to below 25km, then following it from the tracking station instead of "riding" it would have been an option, but I would have needed to know this would happen when making the disposal dive maneuver with my "janitor" ship (which had enough fuel to do this and pull up safely, but unfortunately performed this maneuver well before the quicksave I was using when bringing in this piece: in the interim, other pieces of junk were put into their disposal trajectories and/or brought down). Of course there is also the most obvious workaround: issuing the "range safety" command to the problematic junk, but if were going to do this, I would not even have needed the janitor ship in the first place. I'll keep this in mind for future space junk removal operations.

I recently sent up a "janitor" ship to grab several pieces of space junk with a claw, and then dispose of them by putting them into suborbital trajectories. One of the pieces was from a large craft that uses a system of boosters to lift off from Kerbin, specifically, part of one of its boosters (one of two large fuel tanks and a nose cone apparently broke off when it impacted some other object during jettison). The junk in question consists of the largest fuel tank, a mammoth engine, a horizontal stack separator, and three of the extra large fins resembling shuttle wings, (which are all on the same side of the booster (one of four boosters in a symmetrical arrangement) arranged so that there is less than a 90 degree angle between the two fins on the outside, and the other is halfway between. After setting all junk on suborbital trajectories and bringing home the capsule from the "janitor" ship, I began de-orbiting the junk by focusing on it and allowing aerobraking to either bring it down to collide with Kerbin or cause it to overheat. When I attempted this for the piece of junk I described above, everything went normally at first. Then, the mammoth engine overheated at an altitude in the 20k range, and the remaining pieces of the junk began tumbling. Eventually the piece of junk began to spin rapidly, and the velocity began dropping faster than normal. The spinning became so rapid that the navball appeared to be having trouble keeping up and the screen was shaking. I expected that this would cease upon impact with the ground, but velocity dropped to zero before impact with the ground, and then the piece of junk began inexplicably going back up faster and faster. I tried resetting to a point before the junk in question entered the atmosphere and trying again, but twice I got the same result. Although I do have MM, KAS, and EL, this piece of debris does not contain any parts from any of these mods, nor do I have any reason to believe that any of them could be causing the problem. Edit: By engaging the physics time warp (which I usually avoid doing), I was able to induce failure of the connections between the fuel tank and the shuttle wings (which occurred just after the mammoth engine's Rapid Unscheduled Disassembly), and the spinning issue did not occur, so physics time warp can serve as a workaround.

steve_v: Understood. At least things are back to normal and likely to remain that way for some time. Back to eliminating space junk, finalizing my Extraplanetary Launchpads supported colony on Dres, and sending a drill rig to my colony on Pol to enable refueling from there. Over and out.

Acenthyl: There are currently two version of KAS running concurrently, as IgorZ prepares to transition to KAS 1.0. This is actually the thread for KAS Beta (currently 0.7.3). It looks like the issue you are reporting is with the old version of KAS (0.6.2). If so, this is not the correct thread, and your issue should instead be posted in the thread for KAS 0.6.2. Any post by IgorZ in this thread should contain a link to the correct thread. When you get the information you are looking for, you should probably transfer the conversation about your issue to the thread for KAS 0.6.2 if the issue pertains to 0.6.2 instead of 0.7.3, restating the problem on that thread to avoid confusion.

Things are back to normal. The anomaly has disappeared. The Kerbals should be meeting to discuss options in case it returns: would not want to risk, among other things, a collision between the intruder and one of their craft.

steve_v: If it can be enabled on any day of the year, can it also be disabled on any day of the year (without removing MM, that is)?

This anomaly has been detected on my loading screen as well. I have the following mods: Module Manager, Kerbal Attachment System (current and beta), Extraplanetary Launchpads. From the information above, it looks like MM is to blame for this. Has anyone who does not have MM installed experienced this anomaly?

Extraplanetary Launchpads has gone a long way toward my current KSP campaign (which is in Sandbox mode). I now have EL-capable bases on Mun, Minmus, Gilly, Eve, Duna, Ike, and Moho, with Dres one module (the launchpad itself) away from being fully online. I just established a colony on Pol, and should soon begin sending the necessary infrastructure there to support missions to the other moons of Jool, enabling me to avoid having to worry about outbound interplanetary transfer windows for these missions, as well as significantly reduce my delta V requirements. The view from my Pol colony is quite interesting. While I must take resource availability and terrain into account, I prefer to set up bases that are on tidelocked moons on the near side of said moons, resulting in constant views of the planet (the same principle applies to my base on Duna, which is mutually-tidelocked to Ike). With Pol being the outermost moon of Jool, this results in a view from my base where I can not only see Jool itself, but also Tylo, Vall, and Laythe (Bop is too small to be visible from Pol). I am still waiting for the scrap metal storage issue to be resolved, but am currently working around it by moving my spent workshop modules (which double as a means of re-crewing) out of the way. Junk is starting to accrue at my base on Gilly, from which I have launched most of my recent missions, and thus it tends to require re-crewing most often. Without this mod, it would not have been possible to perform my original Eve landing the way I did, due to aerodynamic constraints imposed by Kerbin's atmosphere. I have not had nearly as much trouble with any mission since. It was because of the Eve mission that I went looking for a mod with this functionality, which is certainly among the biggest things missing from the base game (if not THE biggest). Bases with refueling systems are good, but bases with launch sites are better. The only mods I have right now are EL and its prerequisites (MM and KAS (current and beta of upcoming new version)). I am looking forward to the missions I have planned for the remaining moons of Jool, as well as Eeloo. Great work, taniwha.

Oh, that's the problem. I have done a lot from the VAB but nothing from SPH. Jarin did say SPH above. I'm assuming that means he needs to use a different stake. Is it -X or -Z?

Sideways, you say? Suppose you were to draw a line through your -Y stake that runs horizontally and is orthogonal to the vertical axis of your craft (i.e., the axis which would be up and down if your craft were correctly oriented for launch). Now suppose that the craft were pivoted about that line until your craft's vertical axis matches true vertical. Would it then be completely above the ground? If the answer is yes, you are probably having an axis ambiguity problem. It is possible that by placing only a -Y stake, you have confused KSP and/or EL about which axis should be where. With your -Y stake still in place, try explicitly defining the X axis by placing -X and +X stakes (making sure to place them farther apart than the largest non-vertical dimension of your rocket). EL should decide where to place your ship along the X-axis by taking the average. With one axis explicitly defined, KSP and/or EL should have an easier time figuring out which way Y should be. If even this is insufficient, try also explicitly defining the Z-axis. If I recall correctly, in the event your defined X and Z axes are not perfectly orthogonal, KSP and/or EL will make them orthogonal by evenly distributing the error among the affected axes (e.g., if you set an 80 degree angle, they will both get moved 5 degrees away from each other to compensate).

While I do not use survey stakes myself, from what I know about them (and I just double-checked an earlier post by taniwha: see top of page 184 for more information), it sounds like you need to use a -Y stake. This will define the lowest altitude where any part of your vessel can be, forcing it upward, where it should avoid the ground. Remember, KSP uses Y-up coordinates, and most people are used to Z-up, so make sure not to confuse the two. Also, be aware that a +Y stake in a flat area is a recipe for Rapid Unscheduled Disassembly, so if you mistakenly planted one of these, remove it.

ZorbaTHut: If you have a save state with your base in a known good configuration, you can use it to reset your base in a newer save state to "de-Kraken" it. You will need to override a few lines of code, especially those pertaining to crew. Also, it is a good idea to consistently save your base with full resources if possible (except for any that for whatever reason should be empty), so that any SFS-edit you perform will not affect your resource levels. For example, if you just fueled a ship using standard KSP resources, use your ISRU and drills to top off on fuel and ore and then save. I also have Extraplanetary Launchpads (for which KAS is a prerequisite), and I have made it standard practice to top off metal resources before issuing the "Finalize Build" command, and ensure all fuel tanks (not just those in my base) are full before issuing the "Release Vessel" command, unless I have some reason not to (like if the vessel is part of metal resource infrastructure, and thus should travel to its destination with the tanks for the metal resources empty). In these cases, I top off after completing the mission and before starting a new one from that same base, and save after topping off. The new "physics easer" is helping suppress the Kraken, but recently, I have started to have a bit of trouble with my base on Gilly (perhaps due to accumulation of minor errors). I have noticed that sometimes it will look like a Kraken is trying to start only for things to return to normal. The nature of the Kraken also seems to have changed since 1.2, particularly on Gilly. Instead of ever-increasing wobbling followed by Rapid Unscheduled Disassembly, my base seems to try to come off the ground a bit, more recently trying to cause one of the modules to tip over. Be sure when timewarping a large base not to increase or decrease your timewarp level too rapidly, as this tends to increase your chances of a Kraken.

Agnemon: An interesting thought, though I had hoped to only have to replace my recyclers once to reconfigure for EL 5.7.1 and beyond.

FYI, the build progress catch-up bug has persisted into 5.7.1, as just confirmed when I started building a metal mining rig for Dres at my Minmus base. All previous EL builds since 5.7.1 came out were Gilly to Moho missions, so my Gilly base never managed to accrue enough backlog to trigger it in those cases. I have not yet attempted the workaround since 5.7.1 came out, but have no reason to believe its efficacy would have been compromised. On the other hand, of my Gilly launchpad's four KAS connector ports, two are always occupied by winches from the workshop module and fueling rig, and a third is being occupied by a second workshop module which originally served as a transport, allowing me to send 11 Kerbals to a base at once (it has a cupola on top for command purposes). The fourth is now occupied by a derelict and detached workshop module (i.e., junk that needs to be recycled). While I can still probably launch 2-3 more manned missions from that base before I would want to re-crew again, there would then be the problem of both possible connection points to the Launchpad being fouled by junk. Even if I move it out of the way, junk would continue to pile up near the base until I have the means of efficiently recycling it into scrap metal. This situation is most serious at Gilly with one connector already fouled, but my bases on Minmus, Ike, and possibly Moho (completed with the recent missions) would eventually be subject to the same issue. I am hoping that Tex_NL's complaint has not deterred you from addressing the scrap metal storage problem. I do not have any issue with the aesthetics of the current storage containers myself, and am more concerned with making a recycling rover that is compatible with the new system (and feeding the junk and the old recycling rover to it). Edit: I can now confirm that, as suspected, the workaround for the build progress catch-up bug is still working.

In addition to these issues still persisting for quite some time (mainly causing me problems when launching from Gilly), I am now experiencing another maneuver calculation issue while attempting to calculate a Cis-Moho Injection from Gilly. This time, the problem is occurring during calculation, instead of during the resulting burn. The intercept indicator keeps locking on to a "false intercept" shortly ahead of my position but nowhere near Moho's orbit, instead of the node (descending or ascending) near the intersection of the calculated orbit and Moho's orbit. I may be arriving way early or way late, but I need to know which to know what adjustments I need to make to my orbit to get an encounter, and that can only happen if the intercept indicator tells me what is happening at the appropriate node instead of getting distracted by a "false intercept". It would be very helpful if the intercept indicator could be adjusted so that "false intercepts" could be ignored. My current mods are EL 5.7.1, MM 2.7.5, KAS 0.6.2, and KAS 0.7.3 (0.7.3 is a Beta of an eventual 1.0, and is non-conflicting with 0.6.2, according to IgorZ). However, I do not believe any of these mods could be causing the problem. Perhaps one way to eliminate/workaround this problem is allowing for orange and purple intercept indicators if the target is a celestial object (at this point, this only happens if the target is a vessel). This way, even if the orange intercept indicator got distracted by the "false intercept", the purple intercept indicator would then appear on the correct node, allowing me to see what is really happening (whether I am early or late) and take the necessary corrective action. Edit: I tried making an SFS-edit to move a piece of space junk into Moho's Hill Sphere to lock on to as an alternative target, but no intercept indicators appeared. When positioning the junk just outside of Moho's Hill Sphere, I was able to get an intercept indicator, but it failed to provide me with sufficient accuracy due to deviations between its orbit and that of Moho (which become significant in the time it takes for Moho to move from its current position to the intercept position. Edit #2: After double-checking with Alexmoon's calculator, it appears I have gotten very unlucky as to the time my vessel was completed (via Extraplanetary Launchpads) and launched from Gilly. This suggests I will have to try a different, riskier, and more aggressive approach with my burn. Edit #3: The strategy change enabled me to get a good intercept, and my vessel is now safely on the surface of Moho. Edit #4: This bug has now also been observed while attempting to intercept Bop from Pol, occurring when my trajectory re-intercepted Pol. Looks like it is not just interplanetary trajectories that are affected, but also interlunar trajectories at Jool.