edrobotguy

The problem is that you have a smaller monitor than taniwha. He has the default kethane popup window set 1389 pixels to the right, so if your monitor is less than 1400 pixels wide you won't see the kethane window. Solution: go into the GameData/Kethane directory and open the settings.cfg file. Change the WindowLeft parameter to 500 then save the settings.cfg file. Taniwha, this is something you should probably change for future iterations of this mod.

Please note that the VERSION file contains this: "KSP_VERSION":{"MAJOR":1,"MINOR":5,"PATCH":1} Should this be "MINOR":6 instead?

Solution: go into the GameData/Kethane directory and open the settings.cfg file. Remove the line that says Debug = True and change the WindowLeft parameter to 500 then save the settings.cfg file. Edited to add: you didn't do anything wrong, you just have a smaller monitor than taniwha.

Taniwha, is there anything we can do to help you get kethane working for 1.3?

I've been having the same issue. I currently have one craft that has 13 Kerbals on board, and several other craft. When I moved these 13 kerbals from their launch vehicle to their orbital craft, I noticed that another craft which only has 4 seats was reporting 56 Kerbals on board The problem goes away whenever I go to the tracking station or space port. I've been having this issue since TACLS 0.12.9, but currently have 0.13.0 installed; it happens whenever a Kerbal goes EVA or transfers from one vessel to another. I'm using KSP 1.2.2, 64 bit Windows version.

The toolbar does indeed work in 1.2.2, however most of the mods that I used to access through the toolbar now have sidebar icons. The only mod I have now that really uses the toolbar is Mechjeb, because I find Blizzy's method more useful than the existing Mechjeb drop-down.

Not for me and at least one other person up thread. All that I changed was going from KSP 1.2.1 to KSP 1.2.2. It's such a rare error that I think the problem is not with this mod at all. Instead, I suspect I may have gotten a corrupted file when I downloaded KSP 1.2.1., or something in that download was saved to a bad sector on my disk. Installing the exact same mod (I keep extracted zip files of mods in a separate folder before copying them to Gamedata) in 1.2.2. gave me the desired clouds and city lights.

So, curiouser and curiouser. I downloaded KSP 1.2.2 and then tried again, with just EVE and Boulder Co and MM 2.7.5. and now there's clouds. I guess Squad nudged something in their code between 1.2.0 and 1.2.1 that made this mod not happy, and then they changed something else between 1.2.1 and 1.2.2 and now EVE is happy again.

I have a similar problem to Decus91. After reading through this part of the thread, I downloaded the latest version of the BoulderCo and EnvironmetalVisualEnhancements mods and installed them (correctly!) in the GameData folder of a unmodded version of KSP 1.2.1. I also installed ModuleManager 2.7.3., which I already had. At the end of the loading screen ModuleManager said 0 mods installed. I tried again with a new copy of ModuleManager 2.7.5. Nope. Tried again without any ModuleManager. Nope. Still no clouds, no response from Alt-0. Is there some main graphics setting in the game that needs to be set for this mod to work that I may have changed? Or is this mod just not playing nice with ModuleManager? Is my computer a piece of crap? Does the problem lie between the keyboard and the chair? Is there a corrupted file in GitHub?

One vessel that did not appear as PreLaunch for me was "Dodrin's Wreckage", a rescue mission. That countdown timer started immediately, even though I haven't been within 2250 meters of him. Poor Dodrin, stuck in a 6000 km retrograde orbit. I have a rescue vessel on the way, but he's gonna suffocate before I get there. Well, he would if I hadn't reverted to an earlier version of TACLS. Sorry, no logs, as reversion to an earlier game state wiped those out.

Yeah, I know. I really wanted to do this in stock. That CoMOffset for the Rapier just wreaks havoc with takeoff. (Notepad.) Meh. Maybe I can do it without the Rapier.

Because I'm trying to make the smallest SSTO I can. I guess it doesn't matter. I can edit the CoMOffset variable myself.

This is not a gameplay issue. This is a bug. I have a very small ship, the Rapier is half the mass of the craft, and the CoM is in front of the ship. The center of mass of the part should be inside the part. If the part is actually longer, make the part model longer.

I've been trying to make a minimal SSTO using the RAPIER engine. I found that when adding the engine to the back of my craft the center of mass moved forward. Looking at the part definitions, there is no immediately apparent difference between version 1.1.3 and 1.2.0, both of which have a CoMOffset = 0.0, 2.6, 0.0

At some point, the cost of quality control exceeds the benefit. it isn't worth it to try and ferret out every possible set of conditions that could cause a bug, especially under time and budgetary constraint. This is particularly true for games, unfortunately, as the market turnover rate is very high. A production house wants to put out the next game, not try and perfect one thats five years old. KSP has developed differently. For any other game, this would be development hell. Instead, it became a labor of love, and the modding community got so involved that quite a few top modders got hired. There has been a lot more care put into making the game the best that it can be for something that has been in development (1.x designation notwithstanding) for so long. I never expect to see a fully bug-free anything. That might be the only thing that eventually saves us from Skynet ever happening.

Oh, I know, believe me. I've been programming computers for more than thirty years. Tore my hair out long ago.

Happy to report that updating B9PartSwitch resolved the issue of competing textures. I'm looking forward to the full release. I'm also looking forward to the eventual bug-free version of KSP itself. Hey, I can dream...

Ah, I thought all of B9 was bundled together. Thanks!

That would be a great place to start. Where would I find this? Because the download link on the first page is to b9 v6.1.2 for KSP 1.1.3, which includes B9PartSwitch v1.4.3.

Good thing I really know what I'm doing, then. Yeah, I know it isn't compatible yet. I just hadn't seen that particular issue reported yet, and figured you ought to know.

I'm using KSP 1.2 build 1586 and B9PartSwitch v1.4.3

I've just been playing in sandbox until this mod gets updated, as I have a save I've been working on since 1.0.5 that relies heavily on some B9 parts I'm currently missing. I have an issue I haven't seen reported here. In the spaceplane hangar, when I use the Mk1 1m or 4m body sections it looks like the game is trying to apply two textures at the same time, and that they're fighting each other. It flickers back and forth between the textures. I can't tell you if the 0.25m, 0.5m, or 2m ones have the same behavior, because they're not showing up at all. The following showed up in my output_log: @blowfish, do you need the whole log or does that help?

On the first page of this thread, first post, you'll see a button to download the pack from Github. Download and unzip it somewhere on your hard drive. Then go into that unzipped folder and find a subfolder called GameData. Copy everything inside that folder into the GameData folder in your installation of KSP. The current version of B9 is compatible with version 1.1.3 of KSP, and a version compatible with 1.2 is being worked on.

Well, I have the latest version of b9 installed, but I was wondering about stuff outside of b9 that b9 depends upon. Looks like Blowfish answered my question.

I've updated Firespitter to the 1.3 version and I'm still having problems with some B9 parts not showing up (0.25m M1b, 0.5m M1b, 1m M1b. The 2 meter shows up) and some bizarre things happening to the texture on the 2m Mark1b in the SPH. What other dependencies does b9 have besides Firespitter?