Claw

I'd have to agree, that sounds strange. Are you running other mods? And I assume KSP v1.0.4? Those engines are not listed in the fuel category for me. That's an interesting one. I'll add that to the list of things to look at. Cheers, ~Claw

This is quite odd. It's been a little bit since I've dug in hard into the crew pieces of a save ship, but generally when they ragdoll in the seat, they don't become a separate part of the ship. Do not delete the EVA part from the file. It will mess things up. What you could do is replace the EVA part with an inert part, like a cubic strut. Often times it's as easy as replacing the part name, and the game will take care of cleaning up the rest of the modules, etc. Then do the rest of what you say (adding him back to another crewed part. You'll also need to update the Crew Roster with his idx, which is the seat position number in whatever part you put him in. Two kerbals can't be in the same seat... Really I'd need to see a little more of your save to be able to tell better. Or possibly some pictures. Though you should be able to do the part swap out, so long as you update the crew roster and crew capsule appropriately. Possibly your bug was made worse (or unique) because of other add-ons...? No, my patch does not address this issue. At least not as you've described it. I'm not sure it would break anything in this case, since it's looking for things specific to a Kerbal on EVA (namely that the kerbal is the only part), but it definitely won't help. Cheers, ~Claw

It's up to you. Not required, but you can depending on your gaming goals. There might be a few oddities, like if you have active flights without enough chutes or something on it's way to Eve for an aerobrake. Those might require some additional work to "rescue" from potential demise. Cheers, ~Claw

You can also try this, if you don't want to install add-ons. http://forum.kerbalspaceprogram.com/threads/75586-Master-Thread-Unresponsive-Kerbals-in-EVA (Moved to support.) Cheers, ~Claw

Well, I suppose my point is that people aren't looking because they are hung up on the obvious thing. I didn't have time to mark up every photo, but take a look again at the Mk1 pictures. Look really close at the Mk1 fuselage on the underside in that photo. It does not have a cyan line. The same thing is apparent in the in the last picture in the sequence also. Note the Mk1 on top does have a line, but the one under does not. Also, neither tank on the sides have lines. And this bug doesn't affect only one part. I have four parts that do it, plus unposted pics of the sci jr. Even if the Mk1 is hartd to see, go look at the FL-T400 again. Also, I don't know if you looked at this picture, where the lines aren't even pointing the right way. If you want to upload a .craft, use a site like google drive, dropbox, or mediafire and post a link here. You are right, I am not seeing your real concern here because all of the hard data is reliant on a piece of the game that I do not trust. That is the reason I posted all that above. To say stop pointing at and trusting the overlay. I am very sorry that whatever issue you are having has caused you to quit KSP. I dedicate most of my playtime to finding and fixing bugs for others, because for some reason I want other people to enjoy this game as much as I have. It is incredibly hard to get into some of these bugs. With only someone else's subjective assessments of a plane with no craft files, it takes me days to even guess what you are really seeing. I also never said I don't believe you. I just said I am not convinced, and that's because I haven't seen whatever it is that you are seeing. I'm not trying to be difficult here. I am literally begging for help.

The launcher...sometimes it has...problems. See if it works okay running directly from KSP.exe. Cheers, -Claw

Awesome, glad I could help! Also, welcome to the forums! Cgeers, -Claw

And you did a fine job, although craft files would help. Well, my point here is that it could be a variety of reasons why it's pulling at high altitude. I'm trying to convince everyone to not immediately bite off on the display, assuming it is 100% accurate. Okay, you are indeed correct. Your plane does not appear to suffer from asymmetric rollback or flameout (at least in the profile I climbed). I was going to write up a huge assessment of my flight with your plane, but it's getting late and there's a lot more that I want to write up. From the first post I assumed your craft would exhibit some lateral directional instability (in yaw) because you have a relatively small tail for such large intakes out front (the quad couplers). This is going to cause some "hunting" around. At high altitude, where you are likely at high speed, this hunting eventually turns into a yaw excursion and departure. So, to test my instability theory (which may not be complete, I'll grant), I simply capped the side fuel tanks with a nosecone and moved the eight intakes onto the tail. Two fold change here: Removes drag from up front, and increases stability in back without adding more tail. The result is that flying with the modifications made for a more directionally stable aeroplane. I did NOT fly this through the whole envelope, so I don't swear that this fixes all of the problems. Just trying to show that there's more than one thing at play here. There's actually a lot of stuff to point out in these pictures (a lot), but I simply don't have time. One of the interesting things is that more lines were disappearing than the one that we've been posting about. Now, that being said, to show what I mean about two things... 1) I don't believe the aero overlay is perfectly telling the truth 2) Demonstrate what I mean by "experiment and uncover the truth" I spent a lot of time this evening flying the above plane around. Upside down, spins, stalls, high atmosphere, dives, increasing and decreasing body lift, all kinds of things. It's a fine plane, and hunts around a bit, but I've already discussed that. My point in this post is going to be aimed at the overlay in hopes to show you how to dig at something and to also show that I don't believe you guys ought to be trusting the overlay as a smoking gun answer to your concerns. What follows is a shortened and condensed version of my testing, again because it's late and I'm sleepy. So, in order to attack the overlay I did I simply built a 4x symmetric rocket around a central core in the VAB. Then I flew it east, south, and west to see if the lines showed any difference (due to craft directional orientation). I didn't bother with North, since the other three directions matched. For completeness, I should have... Then I tried rolling the craft into different orientations, and in those movements you can see that the line blinks into and out of existence. There's only two pics here showing the change. So, roll orientation matters! Then I flipped the tanks around in the VAB, so that the bottom of the tank is at the top of the rocket. Well, that seemed to matter quite a bit. Everything basically flipped with the tank orientation. Hmm, so what about FL-T400s? So that's even more strange, but notably, the lines are only flipping around on the surface mounted parts...and not the stack mounted ones. So, lets try the Mk1 fuselage, since someone said that doesn't suffer from the same problem. So it actually DOES suffer from the same problem, except that it's happening in a different place...under the belly, instead of the right wing... So what's the same between the FL-T800 and FL-T400, but is different than the Mk1 Fuel tank? Lets look at the part files, shall we? Turns out there's a lot of differences, but lets cut to the chase and look at the node_attach, which controls surface attachment. FL-T800 scale = 0.1 node_stack_top = 0.0, 15, 0.0, 0.0, 1.0, 0.0 node_stack_bottom = 0.0, -15.1, 0.0, 0.0, -1.0, 0.0 node_attach = 5.01, 0.0, 0.0, 1.0, 0.0, 0.0, 1 FL-T400 scale = 0.1 node_stack_top = 0.0, 7.72552, 0.0, 0.0, 1.0, 0.0 node_stack_bottom = 0.0, -7.3, 0.0, 0.0, -1.0, 0.0 node_attach = 5.01, 0.0, 0.0, 1.0, 0.0, 0.0, 1 Mk1 Fuel Tank scale = 0.0125 rescaleFactor = 1 node_stack_top = 0.0, 75.0, 0.0, 0.0, 1.0, 0.0 node_stack_bottom = 0.0, -75.0, 0.0, 0.0, -1.0, 0.0 node_attach = 0.0, 0.0, -51.0, 0.0, 0.0, 1.0, 1 Turns out Mk1 fuel tank attaches via the Z coordinate and rotation, vice the X coordinate and rotation. X is the "left/right" of the plane, and Y is the "belly/top" of the plane. Also, to add the the wackiness, turns out that the +/- (sign) value is important too. So what other part is similar to the Mk1 Fuel tank? Ah, the Mk1 structural fuselage. rescaleFactor = 1 node_stack_top = 0.0, 75.0, 0.0, 0.0, 1.0, 0.0 node_stack_bottom = 0.0, -75.0, 0.0, 0.0, -1.0, 0.0 node_attach = 0.0, 0.0, -51.0, 0.0, 0.0, 1.0, 1 So I also tried the Mk1 structural fuselage, and it was the same as the Mk1 fuel tank. I'll spare you the pictures of that one... Lets take all that together then, and see if we can build a craft that shows zero body lift on the booster parts. Almost, but not quite... Anyway, hopefully you can see that there's something else going on here, and it's not quite a smoking gun. Otherwise all of these wacky contraptions would probably be going out of control at some point. But if you roll one of them even slightly, all the lines show up. Not to mention that if I send the things out of control, the lines start pointing everywhere. So, all of this work and time spent, and really all I've (hopefully) shown is that the overlay isn't necessarily trustworthy. I think the craft would have flow much differently from each other if the lines were accurately showing what's going on under the hood. So, this doesn't (in any way) discount that something else might be going on that's causing yaw problems. Especially since I can show you yaw drift with rovers, planes, rockets, and unpowered gyros. There's a bias built into KSP somewhere that causes things to bend in their flight path, not to mention all the other physics things going on. Cheers, ~Claw

About a few removed posts...A thread about classical music should stay on the topic of classical music. If you don't enjoy music, please refrain from trolling or derailing the topic. Cheers, ~Claw

Moved to the modding area. Good luck, -Claw

What Rune says is nearly always the problem. One other thing to check is to make sure the saves folders aren't set to read-only, which can also cause problems. Cheers, -Claw

Ah wow. That's roughly when I started KSP also. Glad to hear you signed on after visiting for so long. Looking forward to seeing more of your designs. (I fixed your link.) Welcome to the forums! Cheers, -Claw

I didn't until you said that... In either case...MMG, welcome to the forums! Looking forward to seeing your designs. Cheers, -Claw

Interesting... Oh yes, and welcome back to your welcome message. Cheers, -Claw

Well, I'm not sure how drill stopage with no power is confusing. I certainly can't run a drill at my house without charged batteries or a plug in the wall. Unless it's one of those hand crank versions, which takes a long time to get through solid rock. In either case, I agree with the "go do something else" idea. The game is very forgiving when it comes to power production and running ISRU while not in focus. Though (as stated) with bad setups, it can take a very long time to harvest. Cheers, -Claw

Hmm. I don't know exactly, but try scrolling all the way to the bottom and see if there's a "Full Site" link in the bottom center. If not, check the bottom left and see if there's a "Style" dropdown (and choose Default). I'll poke around in personal settings, perhaps there's something in there. Also, moved this to the forums questions area. Cheers, ~Claw

I don't know if it was fixed either. I believe the problem was if the setup was such that a small amount of ore was converted to fuel, then a larger amount was mined, the overage on that "game cycle" went to waste. So what would happen was rapid draining with small fractions of excess being thrown away very quickly. Cheers, ~Claw

I'm not sure what you mean. I see them in the engines section and in the "filter by manufacturer" tab. That seems doable, although I'll have to figure out a way to do it that doesn't get overwritten each time you download an update. Incidentally, you were never supposed to have access to the blink rates (that was debug code that was left on...) Besides, the blinking is supposed to get your attention! No worries. Cheers, ~Claw

If you have a stock save, go ahead and post it. I will try and take a look when I get a chance. Which will probably be after I finish some internal cleanup of the current stock bug fixes. Cheers, -Claw

The gizmo tools are your friend. They are often easier to use to manipulate a part than trying to attach it perfectly with the mouse. Also, the sci jr has a slighly different attachment than fuel tanks, if I recall off hand. As for clipping, do what you feel. I would share my personal thoughts on how much clipping, but that really should color your thoughts on how you play. It used to be a bigger sticking point on the forums until after the gizmos were added to the game, because you had to use the dreaded F12 menu previously. Cheers, -Claw

Yeah, it's sort of the classic backing up with a trailer issue. If you have ever tried to back up a car or truch with a trailer attached to the back, you know it can quickly become a mess if not handled appropriately.

I think that's my quote. Something important to note though is that cargo/service bays act different than what that quote is referring to. Items inside a bay are checked for occlusion by the bay itself. If occluded, then it doesn't contribute drag. This id true even if some of it is sticking out of the bay due to clipping. However, I don't believe the trick of "attach inside the bay and use gizmos to slide it out" works because the game is checking actual location of the part. So if you slide the part out of the bay using gizmos, it shouldn't be shielded anymore. That being said, it's supposed to work that way, but I haven't verified. Sould be easy to verify with the aero overlay. Cheers, -Claw

And actually, as it turns out, this won't really prevent claw kraken attacks. I used to think so also, but it turns out to not be the case. It will, however, stop them once they have started. The only problem there is if the kraken has already trashed the orbit, restarting won't fix that if it's been saved. Cheers, -Claw

Pixel Light Count and Shadow Cascades (you can see them in the lower right of the OP). Although I've found that turning them up slightly can alleviate some flickering. I think I was fiddling to reduce lag and set 4/2. Turned out horribly, and was better at 8/4, though I could probably be happy at 4/4. The first setting controls the number of lights, the second controls shadowing. If you have lots of lights and low light count, that can cause some flickering, as can low shadow cascades. Cheers, -Claw

Which I suppose begs the question...is there a place (like the wiki) with additional keybinding layouts? I imagine there is one, and if so, I'd like to add that to my personal knowledge base. Cheers, -Claw