Claw

IRC is Internet Relay Chat. It's basically a chat room. People use it to discuss KSP (among other things, there are lots of IRC channels). There is an official KSP IRC "Chat Room" called #KSPOfficial. You can link there using the "IRC Chat" in the buttons at the top of the forum page. People use it because it is a real time communication tool, rather than tracking a line of thought like a thread. Although some people keep track of chat logs too. Cheers, ~Claw

You are very correct. That's my fault for jumping the gun and not noticing the word "steam" in there. The real fact of the matter appears that the stock craft folders are not there, rather than any problems in the save directory. Likely, if you manually add those directories, it will work. Also, steam installs have (on occasion) messed up file permission settings. Thanks for the point out. Cheers, ~Claw

Yes, unfortunately. I am sure there are plenty examples of where moderator thoughts are questioned as official stance. I don't know if there is a way around this, but we do discuss this sort of thing from time to time. Also, please don't interpret my statement about font color to mean we have some sort of official stance against it. A couple moderators do use different color text (or have used) and some of us try to preface posts with "my personal thoughts." Also, some of us share via PM or within side channels on IRC when asked. Ironically, part of what makes a user appealing as a potential moderator is how they interact within the community. So, it is unfortunate that the relationship changes a bit when stepping to the dark side. Cupcakes are always awesome! Cheers, -Claw

Get KSP out of your "Program Files" directory, Windows is messing with the files. You'll need to either install a fresh copy, or "copy and paste" the directory out. Do NOT use move or "cut and paste" because Windows will keep track of the files (and still cause problems). Common install places would be someplace like C:\Games\KSP. Avoid the desktop, Program Files, or the Documents directories. If you have any saves that you want to keep, you can copy those over separately once you create the new install. Cheers, ~Claw

Yeah, this. Or what Grumman said.

Also, I didn't see what version Scott is using, but jet engines were adjusted again in v1.0.3 (reduced thrust) to offset some of the changes with drag. So it's possible that you aren't maintaining a high enough speed on the climb to keep the engines spooled up. If you maintain a slow speed while climbing (such as 160m/s), the engines will provide less and less thrust as you climb. So eventually you will reach a point where the engines can't provide enough thrust to even maintain altitude. As DeMatt suggests, climb out a little shallower to keep your speed up. Higher speeds will translate to more thrust, which is essential as you start climbing up (where the low thrust and high AoA makes it even harder to speed up). Cheers, ~Claw

Yes, all of what DeMatt says definitely holds true. Additionally the game should give you reasonable readings (in Kelvin) at the poles. However, it's also possible that the game is still generating numbers that are a bit off from what you would expect in "reality" since it's all coming from a series of formulas. Cheers, ~Claw

The unfortunate truth is that, practically speaking, you aren't going to be able to manually edit the file and change the root part unless you are really committed (and lucky enough for the ship to have the right structure). It is possible, but it can be quite a mess to do. You can't get away with just changing part numbers around. The problem is that not only do you have to change links, but the offsets and rotations need to be updated as well. That's the real trick. And they are all stored in quaternions, which are generally difficult for humans to deal with directly (vice something like standard angles). And you are likely correct, assuming the ship in question was the child ship when docked. If you docked the ship and later undocked it, the docking port becomes the root part. So... Another option that might work. Dock something to the ship using the claw. The claw ship should be labeled as a "Station" or higher, rather than a probe or lander. By that, I mean the icon that you see when it's flying around. You can change what it's labeled as by right-clicking the control part (pod or probe core) and rename the vessel. In there, you can also select the type. The type is important for hierarchy purposes. Then claw onto the ship (away from the docking port) and that should reorder the parts. Hopefully that'll allow you to remove said docking port. Cheers, ~Claw

Yeah, I often end up sending them on short missions to Mun and Minmus to boost a few levels before sending them elsewhere. Since (as Warzouz said) they have to come home to level. That being said, I'm sure someone has a "shortest possible" profile that they will share soon. Cheers, ~Claw

I'm not sure exactly what you mean by "I can not bring a craft out of said 'Load' tab option." Do you mean that when you click on "Load" nothing happens? It might help if you can upload a log file. Or, at the least, try opening the debug log by pressing ALT+F2 while you try to load/save a ship and see if it's throwing errors. Often times when something like this happens, it's either because the folders are set to read only, or because KSP has been installed to somewhere like the desktop, program files, or documents directory. Windows will sometimes mess up the game when that happens. Cheers, ~Claw

I share the view that a moderator's words will always be read with an undertone of "official" noted around it. Some users even hold a belief that moderators are Squad employees. The crux of the "if users need special fonts or colors to figure out when you're moderating then you're doing it wrong" is that, when posting in a moderator capacity, it should always be done in an extremely clear manner. One of the things that moderators need to be most cautious about is not inadvertently weaving in personal opinions and thoughts into a post that's meant in a moderator capacity. That's much easier to slip up on if one relies on using color coded words to delineate personal opinion from moderator action. Even worse, is when personal thoughts are posted in a post that locks the thread. It's something that I generally try to avoid, and that (to me) is the essence of "you're doing it wrong" if people can't tell. I have a guess as to which thread you might be referring to. Most specifically, when emotions are worn down, there's always an air of "moderators waiving around their authority" regardless of the capacity in which they act. This is a primary reason why I avoid personally commenting in contentious threads. Which is unfortunate because I certainly have opinions, but have to forfeit some of them for the sake of neutrality. Anything I say pro-Squad (regardless of the color font) comes off as "moderators are fanboys." Anything said that is anti-squad can (and sometimes does) get quoted later as if it comes from squad itself. I'm not sure if that really answers it for you. Cheers, ~Claw

I appreciate the attempts to help, but this thread is a year and a half old. I would guess that the user has either figured it out by now, or quit trying. Cheers, ~Claw

Kerbonauts, I'll be as much of a neutral party here as I can... I'd prefer that we not get into a debate in this thread about wielding (or not wielding) moderator powers to gain an advantage. It's well off topic. If you have concerns about moderators abusing their powers, there are other avenues to address that. In regard to the topic, there is a lot of factual information and emotion in this thread about the history and evolution of Windows x64 version of KSP. As I stated before, with so many topics within KSP, there are polarizing factors that some people simply cannot get past. If you'd like to discuss x64 amicably (as the OP asked), then it's best to stick to factual statements and avoid looking to place blame. You might feel that finding someone to blame is important to you, but it will simply propagate the polarizing factors. Also, as I stated before, bear in mind that regardless of how many times or ways something is explained, some times the "why" will remain a mystery. That being said, I'm now in one of those precarious situations as a moderator. To give some slight insight and perhaps guidance to the rest of this thread's progression, here are the two most basic options I have available: 1) Close the thread for being answered, and straying off topic. 2) Let the thread keep on trucking, and hope that the agnostic notes that I post above pushes the train back on the tracks. * (Yes, there are more options. No, we don't need to debate them.) So I pretty much can't use option 1, at least not for now, simply for the fact that moderators have become involved in this topic. Why? Because that would "add proof" that moderators wield powers to squash down any dissent, regardless of my actual motives. This is the dual hat that we have to wear and be cognizant of. So please, back to the topic. Cheers, ~Claw

Actually, I will venture a guess that it is symmetry inheritance. Even if you never use radial symmetry in the SPH, it still defaults to radial symmetry when placing singular parts. So singular parts, under certian circumstances, will transfer their radial symmetry attribute to children parts. This can happen, even if you have never used radial symmetry, even if it isn't selected. There is no specific stock workaround for this, other than being aware and careful how you build. Even that won't prevent it all the time. If you aren't opposed to add-ons, there's a fix for this in my stock bug fixes (SymmetryActionFix). It has several fixes for symmetry bugs, including defaulting to mirror symmetry in the SPH, and mirror symmetry in the VAB for singular parts. Cheers, -Claw

Looks like you have multiple fairings attached, and they are z clipping. Try pulling off the fairing base and setting the symmetry option back to one (instead of four) and see if that helps. Sometimes the editor will attach symmetric parts even though you are attaching to a single node. Cheers, -Claw

Also, assuming you own a legitimate copy, it helps if you provide more information. For example: http://forum.kerbalspaceprogram.com/threads/126294 Cheers, ~Claw

Strange physics behavior might be attributed to a bad Physics.cfg file (especially with Steam). Try renaming the Physics.cfg file, then verify your game cache in steam. That should force the Physics.cfg to download again. See if that helps. Cheers, ~Claw

Sure. For future reference, you can edit your original post and click "Go Advanced." From there, you can select Answered in the dropdown and save. Cheers, ~Claw

I don't believe it was fixed, but haven't confirmed that myself. Cheers, ~Claw

Yes, this bug has been persistent. Some parts seem to be worse than others. I'm not sure if/when it'll get fixed, unfortunately. Cheers, ~Claw

Cool, thanks. Having current saves might help me develop a fix (when I get some time)! Cheers, ~Claw

Pictures and/or log files would help us out in being able to see exactly what you are talking about, and to try and replicate the problem. Check the sticky if you need help finding the files. Cheers, ~Claw

I've been seeing reports of log spam. You could try opening up the log file using ALT+F2 and seeing if there are a lot of entries streaming by. Other than that, we would actually need to see your logs, pictures, or something else to help clue us in as to what might be the issue. If you need help finding that stuff, the info can be found in the sticky in this forum. Cheers, ~Claw

Well, the reason why it works this way is how the code is handling a lifting surface at zero Angle of Attack. Yes, the airbrake has a lifting coefficient associated with it. So in the VAB (where there is zero AoA), the CoL indicator is moved because the tail fins aren't creating enough lift to overwhelm the airbrake lift coefficient. In the SPH, it's different because the tail fins have enough oomph to override the zero-lift associated with the airbrakes. Cheers, ~Claw

I see a few other similar reports. Try bringing up the error log (ALT+F2) and see if it's throwing a bunch of errors. The other thing you can try to do is move the sliders slightly. There is a memory leak in the tweakable GUI when the sliders are put in certain positions. It usually manifests itself as lag when the right-click options are open (as you described). Moving the sliders slightly might help. Cheers, ~Claw