cgwhite4

It looks like RealHeat has yet to update, and since RH is a prerequisite of RO, Theysen may be unable to move until RH updates. RealHeat is listed as being in the domain of stratochief66 on GitHub, and it looks like he has not been on the forum since July 2: not a good sign.

I had just wrapped up my KSP campaign in the Kerbol system and was gearing up to start a new RSS-supported campaign and figured the EL Survey Station would be useful in that one, so came here to pick up KIS. Looks like my timing was perfect, since you just released an update. However, I also noticed that the topic header still reads 1.6 whereas you have just released 1.7. Would be good to update that to avoid confusion: some users may see 1.6 and think there is currently nothing going in this topic except discussion and no update for them to come and grab. Edit: Looks like my RSS campaign may have to wait, as RO has not yet updated and is currently causing a crash in the loading screen. The problem may be that RealHeat has not yet updated, but its manager appears to have been absent for over 2 months. Perfect timing for getting this mod, but not for trying to start my next campaign.

I do not believe there is yet. This is an issue that taniwha is already aware of, but it apparently has low priority, as it has persisted despite a few patches having come out since the recycler was changed to produce scrap metal instead of metal. Hopefully he will fix this soon.

To purge Krakens afflicting a base consisting of multiple modules connected by KAS winches, I replace the afflicted base in the SFS file with an copy of itself from an older SFS file, preferably the one for the most recent save in which the afflicted base is known to be good. Often times, I notice that the orbit block has changed since the last known good state. Sometimes, I only have to replace the orbit block, but if this does not work, the entire base must be replaced. When replacing the entire base, I must be careful to take into account any crew changes I made since that time, and make the necessary adjustments to compensate for this. I also need to take into account any changes in resource levels that have occurred. Typically, I do not have to worry about this because I usually keep my tanks full at my bases (except for the Extraplanetary Launchpads resource ScrapMetal, which I keep empty), and I do not bother with electricity levels when making these changes. Kerbal Joint Reinforcement seems to be very good at preventing Krakens at bases containing KAS-winches: since getting KJR, I have not had to do this again up until this incident. Please note, however, that the above procedure should not be attempted if you have made or broken any KAS winch connections for the base experiencing the Kraken since the save whose SFS file you are wanting to use to fix your vessel, unless you have reverted these changes. I have accidentally "deleted" an EL-supported recycler rover once by making this mistake after having forgotten I had attached it to my base since the known good save, and had to recover the rover from an SFS file where it was detached. Thankfully, said rover was unmanned. Also, if your base contains the 3-man command module and you have moved any crew into it, this procedure can also cause an issue where the Kerbal you SFS-edit into the 3-man command module will fail to be assigned a specific seat and will thus not appear in the portraits at the lower right, making him or her unselectable. If you have an empty seat in another module, it is better to put that Kerbal in the empty seat and then transfer him or her into the desired seat in-game. Another possibility would be an EVA if conditions are right for it.

It had been a while since the Kraken had caused me any trouble at my bases with several landers attached by KAS winches. I had changed some procedures I use to reduce the chance of a Kraken. When a vessel I was attempting to send to Laythe had problems with wobbling throwing my maneuvers off, I got Kerbal Joint Reinforcement to fix that issue, and that started a long run in which I did not encounter a Kraken. Then, just a little bit ago at my base on Vall, where I have two landers attached with a KAS winch connection, as I was attempting to bring in a third lander to connect to those two, as I came within 200m of them, they were hit by the Kraken, promptly resulting in Rapid Unscheduled Disassembly. I find this strange because my base on Pol has seen a lot more activity than that on Vall, and because of an issue affecting Extraplanetary Launchpad's recycling system, I have lots of junk scattered about my base on Pol. I have even experienced lag while bringing vessels within a couple kilometers of that base, but it is Vall and not Pol where I end up experiencing the first Kraken after having installed KJR, which I did prior to KSP 1.3. I believe this is the first time I have made a winch connection where both the winch and the connector port were created after 1.3 came out. While I have created a few vessels with winches since KSP 1.3 came out (and after updating KAS and KJR to their current versions), all connections they were involved in were to pre-existing connector ports, and none of them gave me any trouble (one of them was even on Pol at the base with lots of junk near it). This would in fact be the first connector port not from KAS Beta to which a winch was attached since KSP 1.3 came out. My current mods are MM 2.8.1, KAS 0.6.3, KAS Beta/New 1.0 (most recent patch), EL 5.8.2, and KJR 3.3.3. Also, this was not the first time I had revisited my base on Vall since making the connection in question. When my third lander arrived in orbit above Vall, it was night at my base, so I went there to timewarp forward until there was sufficient light at my base for a safe landing. There did not appear to be any problems at that time. Hopefully, I can fix with an SFS-edit similar to those I used to use in just this kind of situation. Edit: Usual SFS-edit for clearing a Kraken did its job, but still wondering why it happened in the first place after so long without one.

The rover I just brought into my base on Tylo (which contains an EL-launchpad) was created and launched after 6436.42780 came out. It is on the JS-1 side of any connections which are made to it. When I connected it to the metal resource handling rovers (EL-supported base) and then switched to the fuel resource handling rovers in order to move them into position to be connected to the launchpad, the newly formed connection between new JS-1 and old TJ-2 suffered the aesthetic anomaly. Furthermore, I then "respawned" (by disconnecting from all other rovers, creating a new version at Kerbin, and then doing an SFS-edit to replace the old version on Tylo with the new one) the fuel resource handling rover that is meant to connect directly to the launchpad-containing rover (this one contains an ISRU from EL), and after moving it into position, made the appropriate connection with it. When I then switched to the other fuel resource handling rover (contains drills from EL) which will need to be connected to the one I just respawned, the newly formed connection between new TJ-2 of the ISRU-containing rover and new JS-1 from the launchpad-containing rover also suffered the aesthetic anomaly. Edit: The same thing happened after connecting the rover with the drills to the rest of the rover system to the connection formed in the process. The rover with the drills was also "respawned" prior to making the connections. By using the blue and orange illumination of the crew transfer system, I was able to confirm that all connections were still actually attached, and was able to wrap up the mission. That brings my base on Tylo fully online, so I'll be shifting my attention to colonizing Eeloo and upgrading my base on Vall (which consists of landers attached via winches). However, my base on Laythe uses rovers, so I should eventually need to perform similar operations there, and I expect to encounter the same issue again on Laythe should it not be patched prior to that point.

ockidj: When did this issue first appear? Did it first appear immediately after KJR updated to 1.3? If so, please note that RO itself has not updated to 1.3 yet. Even if the 1.2.2 version of RO can run under KSP 1.3, there may be a compatibility issue between the new version of KJR and the old version of RO which could make it appear that KJR is at fault. If such a compatibility issue exists, you may have to wait for RO to update (but given that RO has many prerequisites, RO may not yet be able to). A similar issue occurred between MM and KAS, preventing me from even reaching the title screen until KAS had updated.

Upon attempting to bring the final rover into my base on Tylo to complete it, I encountered an aesthetic anomaly. The connectors between my remaining rovers appeared as though they had become disconnected when the rover in question came within 200m of them (I have experienced such issues in the past, particularly on Eve). However, this time, upon checking the connectors themselves, the options that were displayed clearly indicated that they were, in fact, still connected. Disconnecting and reconnecting the affected TJ-2's corrected the problem. This was the first time I did anything with that base since the most recent KAS 1.0 patch (6436.42780) came out, so I suspect this issue had something to do with it. My current mods are MM 2.8.1, KAS 0.6.3, KAS Beta/New 1.0 (most recent patch), EL 5.8.2, and KJR 3.3.3. If anyone sees TJ-2 connectors that appear to have disconnected for no apparent reason after installing 6436.42780, they may not actually have disconnected, particularly if you would expect them to slide in relation to each other if they were disconnected and they are not doing so. This aesthetic bug can easily be cleared, provided you are not on such a slope that disconnecting the TJ-2 will cause the objects to slide in relation to each other, possibly preventing the connection from being restored. Edit: The issue recurs after exiting the game and returning. Workaround is only temporarily effective.

While attempting to bring one of the rovers for my EL-supported base on Tylo into the 200m area around two connected rovers used for fuel production and that were in existence prior to 1.3, a red message (something like "unable to restore link") appeared and the link between them failed. Looks like another compatibility issue (similar to what happened after one of the 0.7.X patches when a module got changed). Edit: Allowed the two rovers to disconnect and then did an SFS-edit to "override" the rover containing the extendable connector with a fresh version, and was able to reconnect the rovers and continue.

With KJR having taken so long to update, I had forgotten about the scrap metal storage issue until today, when I was decoupling a module from my EL-supported base on Pol and remembered all the junk I have piled up in the area. Remembering that a new patch had come out in the interim, I double-checked in the VAB and that issue has persisted into 5.8.2. I may end up colonizing the entire Kerbol system before this gets fixed: I now have colonies on every major celestial object in the Kerbol system that can be landed on except Eeloo (and of course, Kerbin itself), and have a launchpad at all of those colonies except Tylo, Vall, and Laythe. Edit: Now, I am having a problem at my base on Pol. As I attempt to launch a rover mission to Laythe, one of those workshop modules that has been disconnected from my base somehow gets launched kilometers skyward. I wonder if this is because I have accrued too much junk near my base. Edit #2: Turns out one of the pieces of junk that had accrued near my base had picked up a bug before I even released my newest vessel and was floating about 3 kilometers above my base. An attempt to fix it with an SFS-edit somehow failed, so that left me with only one option: "range safety" it.

Good thinking to give us a total productivity indicator on the launchpad UI. Now, if a build fails to progress despite having sufficient resources, we can check the leading cause without even leaving the launchpad UI, and it will even warn us if productivity is zero before starting a build. I had been in a hiatus for a while due to needing KJR to update for my Laythe Landing mission to go forward on its most recent iteration, but now I have back up and running, and I've even managed to land on Laythe and get the vessel back up to a parking orbit, making mission success almost certain, as I can send a tanker from Pol to refuel the craft if necessary (it still has 4 boosters attached, so should have enough tank capacity to get the crew home to Kerbin and slow down on arrival to avoid burning up).

Update complete and all appears to be well again: no wobbling during the interlunar burn to get to Laythe from my Extraplanetary Launchpads supported base on Pol. Time to resume landing attempts. Edit: The iteration of my craft that had been waiting on the pad for KJR to update got the job done: good landing, good return to parking orbit (the latter taking several tries due to having to make everything go just right to avoid a re-impact problem during outer booster jettison). Very little chance of failure now, as I can send tankers from Pol to refuel if need be.

ferram4: Thanks for the status update. It is good to hear that you are close to updating KJR. Hopefully, the remaining tests you need to run will give satisfactory results. I am looking forward to the release of the new version.

I already tried autostrut for my Laythe landing mission, and it did not help. KJR is what was allowing that mission to get through its initial burns to the point where enough weigh had been lost that it was not needed. Although I did have an iteration of this mission beyond that point when 1.3 was released, I was forced to revert to a save just prior to starting its construction (I am using Extraplanetary Launchpads as well), due to having insufficient parachutes on that version of the craft to land on Laythe without taking unacceptable damage (I also have somewhat of an "expendable shock absorber" on the bottom of the craft for lithobraking, but without more parachutes, it does not provide sufficient protection).

I would hope that in the event a mod maker determines that he or she is unable and/or unwilling to continue maintaining a mod, the mod maker would post a message to this effect to the thread of the affected mod, so users of the mod know that further updates will not be coming. Mods sometimes change hands: I am aware of at least one other mod doing so at the request of the original mod maker. Such an event would surely be accompanied by a message from at least one of the individuals involved. In the absence of any messages indicating either of these scenarios, we can only assume that ferram4 is continuing to work on updating KJR, but is being delayed by RL issues, is having a particularly difficult time of it this time around, is giving priority to another mod for which he is responsible, or some combination of these. There are numerous reasons why a mod maker may be particularly silent on the forums during this time. It could be an effect of RL issues, but it could also be the result of a decision to redirect the time that would be used for making forum posts to updating the mod, or some other reason entirely. Many of us surely find this situation frustrating, especially for those who cannot advance as they had planned without the functionality of KJR, those for whom this is the last mod they are waiting on to update, those who have tried an unofficial solution (such as the one siimav is offering) and found that it did not work, and those who consider unofficial solutions too risky. However, it should also be noted that finishing a patch for a mod and releasing it only to then have a major patch to KSP come out 2-3 days afterward could be frustrating for the mod maker, and ferram4 was indeed this unlucky this time around. We can only hope for an update soon, or at least for word on what the situation is (and hope it is not the bad news I mentioned in the first paragraph).

SnowyShoe: This mod is not yet compatible with 1.3, as per my experience. While it will not crash the game as far as I know, it will fail to provide the intended functionality of the mod. I have heard that KJR tends to take a while to update after a patch, but this delay is significantly above average, if I recall what I read correctly. My guess is there is something about patch 1.3 that is proving to be particularly troublesome for ferram4. I could not even get to the title screen (due to crashes during loading) until 2 other mods I used updated, which is unusual for those mods. This suggests something big must have changed, and the process by which ferram4 will modify KJR to compensate for the change is significantly more time consuming than with most prior patches. I too am hoping ferram4 will soon be able to fix this, but we have not been provided with an ETA at this point.

I am aware that KJR has not yet updated. In fact, I have put things on hold for now due to an unrelated issue caused by KJR not being up to date. Hopefully, ferram4 will update KJR soon. As far as the issue you are reporting, I am not sure that it and my issue are one and the same, as I only started experiencing mine when KSP 1.3 came out and mine is mainly a graphics issue, whereas it sounds like yours could potentially be something more serious. Furthermore, my issue was most noticeable at ten thousand speed, whereas it sounds like yours happens when you move between normal and five speed. If your issue has persisted into KSP 1.3, and you have not yet filed a separate bug report, it may be a good idea to do so. While the problems we are experiencing could possibly be related, this is not necessarily the case. Edit: I forgot to explicitly mention at this point that I do not believe that KJR is the cause of the graphics issue. Its main role is to reinforce joints, and thus prevent my vessel from "wobbling" itself off a maneuver node (or worse, blowing an interstage joint), and although it could be decreasing my frame rate, I would expect the background stars, resource meters, and MET indicator to be adversely affected in the event of a frame rate drop.

siimav: When in doubt, ask the mod maker. At least one that I know of did not object when unofficial patches were posted to the mod's thread while an official update was still in the works. You are certainly correct about the "use at your own risk" part though. Note: Ferram4 also cannot be held responsible for anything bad that happens to a third party because of their use of your patch, even if he declines to object to your unofficial patch being posted to this thread.

While running a large fueling operation at my Extraplanetary Launchpads supported base on Pol, I engaged time warp at ten thousand speed to speed things along, and noticed some anomalous graphics behavior. The resource meters and MET indicator moved normally, as did the stars in the background, but the movement of Kerbol star itself was choppy, and the same was true of shadows cast by the various components of my base, as well as the vessel that was being fueled for launch. I have only run such a fueling operation twice since KSP 1.3 came out, and this anomaly occurred both times. I currently have the following mods: Module Manager 2.8.0, Kerbal Attachment System 0.6.3, Kerbal Attachment System Beta 0.7.4 (does not conflict with current KAS), Extraplanetary Launchpads 5.8.0, and Kerbal Joint Reinforcement 3.3.2. Has anyone else experienced this issue?

It is 0.6.3. It is just mislabeled on curseforge.

Drew Kerman: IgorZ has now reached 667 reputation points, so feel free to give him one without worrying about putting him on a "bestial" number of reputation points (nor does he need one from anyone to move himself off that mark). You'll only be moving him farther from it now, as I doubt many people would be interested in retracting reputation points from the maker of KAS and KIS.

Updating KAS and KAS Beta cleared the issue I was having, despite EL being yet to update (same situation with KJR, but KJR does not add parts).

After updating to KSP 1.3 and entering the game, I noticed an aesthetic issue with the UI. The length of resource gauges has changed in both the staging diagram and the main resource box in the upper right corner. While the change in the staging diagram is favorable, as the bars were lengthened, the change to the main resources bars is not: it has shortened the bars to the point where, with the slash in its current location, numerical values of one hundred thousand or higher cannot be displayed properly in the numerator (they are wrapping to fit to the left of the slash, causing the last digit to appear in a line below). Although I have MM, KAS, KAS Beta, EL, and KJR, none of these should affect this UI element as far as I know, with the exception of additional bars for the resources used in EL, none of which are typically present in quantities anywhere close to one hundred thousand. (Note: KAS and KAS Beta do not conflict with each other). It would be appreciated if in a future patch, either the slash is moved to the right just enough (two 6-digit values should be able to fit on the bar in its current length) or the bar itself is lengthened enough to allow 6-digit values to fit to the left of the slash. I am currently focusing on missions to the moons of Jool, and commonly work with resource values this high (typically fuel resources, but because I have EL-supported bases that are assembled with KAS winches, electricity values at these bases are also 6-digit figures).

Wouldn't that mean visiting any of my bases where winches are present would cause the connections to break (or perhaps something even worse like being unable to load my save)? I do have a mission in progress that could advance without worrying about winches, but to start my next planned mission (or if I discover I need to launch a fuel tanker to support the current mission), I would need to visit one such base.

The good news is MM has updated. The bad news is IgorZ has reported anticipating the possibility of a significant delay on his end.