cgwhite4

Members
  • Content count

    95
  • Joined

  • Last visited

Community Reputation

13 Good

1 Follower

About cgwhite4

  1. [1.2.2] Realism Overhaul v11.5.1 - 06/12/2017

    That spreadsheet is indicating RealHeat as ready. Found the .dll, downloaded it and swapped it for the old one. The warning for RealHeat has stopped, but due to the RO compatibility issue, I still cannot clear the loading screen (which is showing signs of a invasion by dozens of feline aliens most likely sent by sarbian).
  2. [1.2.2] Realism Overhaul v11.5.1 - 06/12/2017

    Abpilot: I would certainly like to see the same thing soon, but I just double-checked (using the link on the initial post in this thread), and Real Heat, one of RO's pre-requisites, has yet to update. Pushing mod makers to update when their mod's pre-requisites have not yet done so is futile (and will only serve to annoy them). If something in Real Heat that RO uses changes when the former updates, the latter must take that change into account for its own update. Real Heat is the only RO pre-req not yet compatible with 1.3 (or at least not throwing loading screen warnings) that I am aware of, so once it updates, everything should be in place for RO to do so as well.
  3. [1.2.2] Realism Overhaul v11.5.1 - 06/12/2017

    That is good news from a RealHeat point of view, but because it is a test version only, Theysen may not be able to rely on it. If stratochief66 and PhineasFreak make changes for the official version, it could render it incompatible with a version of RO that Theysen might construct relying on the test version of RealHeat, and he'd have to make another update to fix it. With RSS having RO as a prerequisite, that could cause a chain reaction that could impact a lot of mods.
  4. [1.2.2] Realism Overhaul v11.5.1 - 06/12/2017

    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.
  5. [1.3.1] Kerbal Inventory System (KIS) v1.7

    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.
  6. [1.3.1] Extraplanetary Launchpads v5.9.0

    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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. [1.3.1] Extraplanetary Launchpads v5.9.0

    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.
  14. [1.3.1] Extraplanetary Launchpads v5.9.0

    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).
  15. 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.