cgwhite4

I can only think of two things here. First, sometimes I have to press the space bar twice to stage. In such cases, it will make the engine activation noise on the first press of the space bar, but do nothing. I am not even sure that is an EL issue (and in fact thought it was a KSP issue). Second, you can have null stages when editing the staging in the Vehicle Assembly Building (VAB). I have always corrected this before exiting the VAB though. It may also be possible to have null stages if components of your vessel get destroyed before you get to them in the staging sequence (e.g., if something overheats during atmospheric entry). However, it sounds like the issue you are experiencing is something different than this. Most likely, if you are using 100 mods, a mod conflict is to blame, especially if you updated any of them right before this issue first occurred.

Agnemon: While I would not call this optimal, there is one workaround that I can think of: putting a smelter (of any size) on your recycler. Of course, the biggest smelters would be more efficient (allowing you to consume larger pieces of junk without wasting scrap metal), but you may have to be careful if you are operating in high gravity conditions (such as the surface of Eve), as a recycler rover with the largest size smelter has been installed would likely be quite top-heavy, and thus prone to tipping over (which could in turn result in Rapid Unscheduled Disassembly). It is probably just better to wait until taniwha provides us with more appropriate storage, but if you are in a hurry to get your recycling program up and running again, this can serve as a stopgap. taniwha: It sounds like we need some scrap metal tanks similar to the red ones for metal ore and blue ones for metal. Perhaps green for scrap metal? Seems to be the most logical color since scrap metal is typically recycled into metal, and recycling is a "green" process. Since I would rather not have to replace my JunkEater rovers twice to get back to the same level of storage efficiency, I'll suspend recycling operations for the time being. It will be interesting to see what color you choose for the scrap metal tanks, and I hope to see them soon in an upcoming patch.

Oops, I must have missed something in a set of old patch notes. Good to know. Sorry about that.

BigJammy: Do not go to the tracking station to time warp when you have an active EL build. The launchpad's UI must remain active for the build to proceed. Even so much as closing the launchpad UI will have the same effect as hitting the "Pause Build" button. Remain focused on your base and leave the launchpad UI open while timewarping. Doing so should correct your problem.

Then it's a good thing that I don't have to, thanks to what we discovered about the update time variables.

While launching a rover to the surface of Duna from my Ike base after having not built anything from it for a while, I noticed that the issue that I had experienced 3 times and was expecting to possibly have to work around again did not occur. Just prior to the start of construction, I had been performing other operations in the vicinity of the Ike base: landing an incoming vessel, operating a recycler rover on some debris and a module that was no longer needed, and performing EVA's (involving making KAS winch connections). Perhaps during my earlier tests involving waiting a certain amount of time before starting a build, I somehow did not wait long enough. My MET indicator does tend to stay yellow while I am operating at one of my bases, though that should not have affected the test involving the time warp.

The issue occurred a third time, this time at my base on Minmus, giving me a chance to watch very carefully for any effect of the bug on the fuel management side of the base infrastructure. The workaround was applied to all construction and metal ore / metal / rocket part management equipment. It was not applied to the ISRU or the drills. After completing the Finalize Build step and ensuring that the resource gauge pane was locked visible, I started the fueling process, and observed no resource level spikes, confirming that the bug is limited to construction and EL-based resource processing.

No anomalous behavior by the ISRU or drills was detected during fueling for the scanner probe mission to Dres I was working on at my Gilly base. The payload was lighter than for most of my launches, so its rocket was also the smallest I have sent to Dres (only about 20k or so liquid fuel would have been required). Thus, I would have expected to observe a noticeable spike in my base's liquid fuel and oxidizer gauges had the issue affected the fueling system as well.

Turns out there were a few more variables. The precise number for any given base will depend on how much equipment is present: one for each auger, two for each smelter, and one for each workshop. Setting all of them and the lastUpdateString variables for all parts with Kerbals in them yields a workaround. As a result, my Gilly base is back in business, and I know what to do if any other base is similarly affected.

That reset the build progress rate to normal, but the smelter is still acting up. There must be another variable of similar nature that controls it.

The relevant math worked out to between 90 seconds and 2 minutes, but waiting (at least) that long after loading my Gilly base before issuing the Build command failed to clear the bug, even when attempted from my main save, which is at a point just before I went to Gilly to begin the build. I also tried timewarping ahead that amount. Still the issue persisted.

MaxDeltaTime is reading 21600, which when divided by 3600 does indeed equal 6. In both instances where I encountered the bug, I had quicksaved after selecting the craft to be built but before issuing the Build command. After encountering the bug, I would revert to my quicksave in an attempt to clear it, but would always turn on the smelter and workshop and in some cases do things like click on all of my parts with Kerbals aboard before issuing the Build command. These have not been the only instances where I have quicksaved after selecting a craft but before issuing the Build command, and since I started doing it, it has only been a problem these two times. In fact, in some situations, I had even ended a session with a ship loaded but no Build order issued. I am also frequently going more than 50 Kerbin-days between visits to my bases, since I am frequently running interplanetary missions and focusing on one at a time, but sometimes when I find that all applicable interplanetary angles are bad, I send missions between objects in the same planetary system (recently, this has been mostly from Ike to Duna). I cannot be sure if there is any pattern to when I have quicksaved with a craft selected but not yet building and how long I have been away from any particular base, but I do know that I had not used my Gilly base since a while before I had the incident on Mun, and since then, I launched a vessel from Ike, landed on Dres (for the first time), and returned to Kerbin, so time away from a base could also be a contributing factor. As for framerate, there is typically a lag during "physics easing", but I typically do not do try to do anything until "physics easing" has occurred (I certainly do not want one of my bases to be affected by a Kraken, as that usually leads to Rapid Unscheduled Disassembly). Some time ago during operations on Eve involving a somewhat similar base, I did notice that I was lagging during resource processing operations, but I would not think it would be that slow. On the other hand, I was not aware of anything about "stored up Kerbal hours". Does this mean that the Kerbals could be somehow contributing downtime incurred before a Build order toward that build, despite not knowing what they would build? Even if so, that does not explain the smelter and workshop processing resources faster than normal, especially since the smelter is unmanned and both were turned off prior to selection of the craft to be built.

I am experiencing a problem with construction. Recently, I returned to my base on Mun after having done nothing with it for quite some time, in order to perform a hardware upgrade. The new hardware was to be built by my base and replace its old equivalent. However, when I issued the "Build" command, the progress gauge shot forward way faster than it should have, quickly arriving at the point where it had used up all of the resources I had made available to it (the workshop was on and the smelter was in recycle mode). Knowing this should not be happening, I tried several things to return operations to normal, including clicking on all parts with Kerbals in them once before starting the build (which had worked for clearing this issue at various points in the past, but not this time). Finally, I had to disconnect all of my modules, replace them through edits to the SFS-file, and reconnect them. Only then did proper construction behavior resume. I was subsequently able to build and launch once from my similar base on Minmus and twice from a similar base on Ike without incident. I then checked and determined that of the locations I had EL-equipped bases, Gilly (where I had built and launched something not too long ago) would need to be the launch site for my next mission (due to having the correct interplanetary angle with respect to the target celestial object: Dres). However, upon issuing the "Build" command at Gilly, the issue I had experienced on Mun recurred. In addition to EL 5.6.0, I am running MM 2.7.5, KAS 0.6.2, and KAS 0.7.3 (a beta version for an eventual KAS 1.0. Note: Current KAS and Beta KAS are non-conflicting, as Beta KAS involves different parts and functions differently). Some of the parts are indicating productivity of zero, particularly the cupolas I generally place on top of workshops. On Gilly, I tried reassigning the seats so that each part that could hold crew had at least one Engineer in it, ensuring that all such parts had non-zero productivity (this is in sandbox mode), but this failed to solve the problem. At one point while I had experienced the issue on Mun, I tried emptying my Metal and Rocket Parts tanks with an SFS-edit to see if this would help me correct the issue. However, not only did it not solve the problem, but when I tried turning the smelter on to slowly feed resources to the launchpad (my workshop was also on at that point), Metal and Rocket Parts were produced much faster than normal. Although Beta KAS updated recently, no parts from Beta KAS are present at either my Mun base or my Gilly base, nor do the vessels I was attempting to build in those two cases contain such parts. The same is also true of my bases at Minmus and Ike, all three of the ships successfully launched between these two incidents, and all recycler rovers present at the bases involved in this situation (which are sometimes hooked up to these bases using winch connections from KAS 0.6.2).

Update to KAS 0.7.3 complete. Main save file edited as indicated. Loading my bases on Duna and Eve did not result in any problems despite having left the connections intact. As a precaution, went to the VAB and performed a remove and replace on all JS-1's and TJ-2's for all applicable vehicles. Main save file updated. I'll just have to be careful not to try to switch to my bases on Eve or Duna if I have to do anything in an older save (such as look for a known good copy of a base like the one I have on Gilly to repair/"de-Kraken" it in a newer save via SFS-edit). Strangely, I was blocked from deleting KAS 0.7.2 until I closed one of my saves which had been open in Notepad++ for SFS-editing related to my Eve base renovation. Normally, Notepad++ does not cause file lock/conflict issues, but instead waits until you return to it and then prompts you to update. The save in question was not my main save, but did contain parts from 0.7.2. Anyone using Notepad++ for SFS-editing should close all save files with KAS 0.7.2 (or close Notepad++ itself) before attempting to update. I suspect the same will be true of other text editors as well. Edit: With my main focus now on Dres, my Extraplanetary Launchpads supported base on Ike now ready, and bad interplanetary angles for all three of my best launch sites (Ike, Minmus, Gilly) with respect to Dres, at least 1 more rover including KAS 1.0 Beta parts should soon be sent to my base on Duna. I should soon have some idea if the issues I ran into on Eve (particularly, connections breaking during "physics easing") were mainly due to specific conditions there (either Eve itself, or the combination of winch and TJ-2 based connections in the same group of rovers during the remodel). My check of my Eve base after updating to 0.7.3 did not cause a broken connection (at this point, all winch connections have been removed), and I am hoping that the issue turns out to be that the old and new connection types should not be used in the same group. Edit #2: Perhaps I spoke a little too soon. While approaching my Duna base with my RollingWorkshop rover, I received a red "Unable to Restore Link: KAS-TJ2" message upon coming within 200 meters of my RollingAuger and RollingForge (which were connected together). The connection had broken, albeit failing to produce the crunching sound that normally accompanies a connection breaking. The two rovers were still within range of each other and neither was violating angle constraints. The other pair of rovers I have at that base (RollingDrill and RollingRefinery) did not experience the same anomaly, and I suspect I know what is going on. If I recall correctly, the RollingAuger was created before KAS 0.7.3 was released and the RollingForge came after it. It appears that pre-existing TJ-2's and JS-1's that have been updated to 0.7.3 work with each other, but may be partially incompatible (can connect, but cannot remain connected when reloaded) with JS-1's and TJ-2's (respectively) that were created after the update. Edit #3: It gets even stranger. Upon connecting the RollingWorkshop to the RollingForge and then switching to the RollingAuger via the tracking station, the connection between the former two also failed in the same manner. Did an EVA as a workaround and was able to continue as planned, but I suspect this will give me more trouble at such point as the Launchpad rover should arrive and everything need to be hooked up. No longer sure partial incompatibility is the explanation: one or the other of the two links in question would be affected, but not both.

The renovation of my Eve base is getting closer to completion: 4 of the 6 rovers have been recreated using the TJ-2/JS-1 connection system, and the new version of the 5th is ready on the launchpad (which itself will be the 6th and final rover to be replaced). I have noticed that my two adapter rovers (designed to allow rovers from the old and new systems to connect with each other) appear to be contributing significantly to the problems I am having with new connections breaking. The physics easing keeps throwing my rovers into the air, but the adapters tend to jump the highest. While they are the lightest rovers present, I do not think that is the entire issue. They are also the "ends" of the ever-diminishing system of winch connections (as well as the "ends" of the ever-increasing system of TJ-2/JS-1 connections). I was intending to keep them in the system due to the metal tanks I added to each, but now I am thinking they are more trouble than they are worth, and I will likely feed them to my "JunkEater" rover once I have replaced the Workshop and Launchpad rovers. Note: the slow going is not just due to connections breaking or going slow to reduce the chance of that occurring. Some events not related to KSP are occurring that I have been following (and had planned to do so). Edit: Renovation complete. Still having a couple issues with connections breaking, but I think the main culprit is the "physics easer", which caused the pad itself to "jump" higher than the other rovers. Being on Eve is probably contributing to the problems as well. I may have to run some further tests on Duna (and possibly Laythe) in the future, but for now, back to what I had been doing before the renovation.

The renovation of my Eve base is underway: 2 of the 6 rovers that comprise my base have been recreated with the TJ-2/JS-1 connection system in place of winches. I have noticed a couple issues. First, sometimes after connections are made and then later released, one of the parts will be listed in the tracking station as something weird (e.g., "Eve Launch Facility Lander Base" when Eve Launch Facility was the name of one of the rovers (multiple connections were released in this example)). It would make more sense for them to revert to their original names. While this is usually only a nuisance issue, on one occasion, it appears to have confused the steering system on the rover being disconnected, so that commands to turn left and right instead cause the wheels to all turn inward or outward. Second, the physics easer is still causing some problems on Eve. It will sometimes cause the rovers to jump a couple meters into the air and then come back down. When this happens, the TJ-2/JS-1 connection will sometimes break (accompanied by a red message indicating an illegal angle and/or distance). Usually, this simply decouples the two affected rovers, but there have been times where either the JS-1 will come loose from the part it was attached to and end up in an inappropriate location, or the TJ-2 will break off.

That sounds like a KIS issue, not a KAS issue. If I recall, the two were once a single mod, but have since been separated (though KIS is required to use the survey stakes in KAS). If you scroll up to IgorZ's most recent post, you should see six links at the bottom. The first of these is for the KIS thread, which IgorZ also runs. In addition to that technically being the correct place to post for your issue, you may find that the information you are looking for is already present on the KIS thread since the issue you are having already occurred at some point in the past. I have KAS but not KIS, so I am not familiar with the issue myself. Best to head over there and have a look. Good luck.

Finally managed to get the rover with the EL Launchpad into position on Eve and get everything hooked up (after having to work through / SFS-edit through multiple issues: it certainly is not helping that my complicated set of winch connections exists on a slope). Another SFS-edit will be required to stabilize the Rolling Auger (damaged by the physics easer) before beginning construction. Once I get a recycler rover to clean up the old equipment and an adapter to allow the old to temporarily connect to the new for resource transfer, it will be time to construct replacements using the KAS 1.0 Beta connection system, which hopefully will eliminate the problems I have been having on Eve.

It now looks like I am getting best results with winch autostruts enabled with respect to timewarping while focused on connected landers. Anyone using Extraplanetary Launchpads (for which KAS is a pre-requisite) like me should take note of this: you may want to manually override the winch autostrut settings for your EL bases. It appears to work module by module: switching the settings for any winch on a particular lander will affect all winches on that lander. Not sure what other mods would be particularly affected. I still have yet to revisit my Eve base in KAS 0.6.2, which is where the autostruts were actually causing me problems (with rover-rover connections). When making rover-rover connections, you will likely want winch autostruts off (otherwise, you will probably blow multiple tires, and if you are on a slope, you may start sliding even if you were stationary with brakes on before making the connection). The TJ-2 connector in KAS 1.0 Beta does not suffer from this problem (as determined by my testing on Duna). In addition to IgorZ's warning about parts changing in Beta, be aware that you will need to get your rovers much closer together to make the connection (close to 2m as opposed to 50m), so be careful with extendable solar/radiator panel placement if you choose to go this route.

Understood. I'm currently only using TJ-2 and the corresponding receptor from the beta parts (JS-1 if I recall). So far, only one such connection is in existence (on Duna). In the event that the notes for an upcoming patch mention a change to these parts, I may go in and disconnect these connections for safety before updating, and then reconnect after the patch. Hopefully, nothing will be so bad that I would have to SFS-edit out my Duna rovers (and any such rovers that may eventually be deployed to Eve or Laythe) to allow my save to load. Edit: After repeatedly encountering a Kraken during an Extraplanetary Launchpads construction procedure (specifically, it occurred when dropping out of time warp to turn equipment on/off) on Gilly, I determined that my "JunkEater" rover, which I had attached to my base via winch to consume off the metal it had produced during recycling, was being thrown into the air, and due to the winch cable, was usually colliding with the workshop module it was attached to. Manually activating the auto-strut for the specific winch in question prevented the Kraken from occurring, and with the JunkEater's metal tank then at zero, I was then able to turn the auto-strut back off and unplug without incident. This was the first time since KAS 0.6.2 came out that I attempted a time warp for a rover connected to a lander (I have not yet attempted a time warp for connected rovers with KAS 0.6.2). If anyone has been experiencing similar issues since 0.6.2 came out, temporarily activating the auto-strut may allow you to proceed: they are certainly causing some problems, but may be preventing others. Lander-lander connections appear to be ok for the most part: one minor issue did occur, but it happened during an EL "Finalize Build" command, which causes the vessel that is currently to spawn on top of a launchpad, invisibly connected to said launchpad until a subsequent "Release" command is given (the connection allows for fueling and, if necessary, boarding). Strangely, the part that was most adversely affected during the "Finalize Build" command was 3 winch connections away from the launchpad, so I may have to try activating auto-struts for all winch connections before issuing the "Finalize Build" command.

Will there be anything new in KAS 1.0 that can make connections across similar distances to the current winch system? Based on my experiences, and a post you made related to KAS 0.6.2, it sounds like auto-struts and winches are not working well with each other. My experiment with the new connectors on Duna looks to have succeeded, but most of my other bases utilize landers (went to rovers for Eve and Duna due to anticipated precision loss caused by drag), and the new connectors would require serious landing precision (and an increased risk of a collision with the target of the connection), as well as the possibility of retractable solar/radiator panel conflicts between the landers to be connected.

After some careful maneuvering last night, I was able to get the my RollingWorkshop attached to the RollingForge and RollingAuger. I did, however, have to forego the use of time warp while processing the resources, as when I tried using time warp, part of the RollingWorkshop would undergo Rapid Unscheduled Disassembly upon dropping out of time warp (probably caused, at least in part, by a structural weak point not standing up well to the physics easer). I am not sure exactly when I will send the final rover to complete my EL Eve base, but it is certainly a good thing that I have the KAS 1.0 beta, as the winch system, while working ok for groups of landers (such as on Mun, Minmus and Gilly), does not seem to be faring well for my rovers on Eve. My Duna base is currently operating on the KAS 1.0 beta connection system, and will continue do so at such point as I upgrade it from refueling to launching capability. Should I get that far, an eventual base on Laythe will also use the new system, and the Eve base will almost certainly be tasked with its own replacement once the final piece is installed. At this point, I have yet to update to KAS 0.6.2, which I will probably try tonight. That "auto-resonance" state you describe sounds a lot like the Kraken that I periodically experience on Gilly, and the "RUD" depicted in the video looks pretty much exactly like it. Hopefully, I will not be forced to revert. I'll be sure to let you know what happens. Edit: So far so good. I even did a hardware replacement at my Gilly base (one element had been damaged a bit from some of the various Krakens), which involved connecting and disconnecting hardware, and no issues occurred. I have yet to check any other base at this point: my current primary target is Moho, so the delta V requirements pretty much dictate that launches occur from my Gilly base. The final rover to Eve will likely be sent the next time I get a bad interplanetary angle when it is time to start a mission.

I now have the penultimate piece of my Extraplanetary Launchpads supported Eve base in position. I am having further issues getting it connected, which I am sure has to do with the auto-strut bug, and having to perform some SFS-edits to get it to work. For comparison, problems on Duna, where the rovers use the connectors from KAS 1.0 Beta, have been non-existent. Once I get the final piece installed, I'll probably just use the facility to replace itself with the new version (and build a recycling rover to recover what metal I can from these problematic rovers). I wonder if the auto-strut issue is also responsible for a number of Krakens I have experienced at my Gilly base (which also has winch connections, but the components are on landing legs, not wheels). The five components there have pretty much remained connected throughout operation though: not being caused by making a new connection, but instead seems to occur when a landing ship is approaching within 200m, or when a ship is lifting off from the EL launchpad. If it is auto-struts, maybe some form of new style connection would help with that too. May have to test it somehow

Sounds like my current JunkEater rovers, which have on-board metal tanks but not scrap metal tanks, may end up being "eaten" themselves by replacement models. On another note, it is good to have Augers working again after 2 outages. Next stop: Moho... ...as soon as I figure out how much rocketry I need to handle the steep delta V demands of the Moho capture burn and still have enough to get back to safety (preferably Kerbin).

flori1994: Unfortunately, the best way is not possible if you are referring to a pre-existing probe, as it would require installing connector ports and/or magnets on the probe (I mainly use the winch/connector system from this version of KAS) to serve as receptors for your connection. If I recall correctly, you may still be able to achieve this with a harpoon-type connection, but doing so risks damaging the probe.