Claw

Many places on the forum. I actually can't remember off hand if it was added to KSPedia. Paging @TriggerAu Meant to say "Many places on the forum, but nowhere in particular." Since the forum won't let me edit my post at the moment, have this auto-added-edit! Cheers

Try launching the game in full screen mode. You may need to edit the settings.cfg file and set: "FULLSCREEN = True" This was causing issues for some folks.

Old thread is old. But the migration of the game engine to Unity 5 has brought up new bugs, both with KSP and with Unity. So we're in the process of wringing out the new ones and getting things more stable. There also seems to be an (unfortunately) unpredictable bug, which has been causing consistent crashes for some folks but not for others. We are in the process of trying to track that one down. But I'm going to close this one for now, so as not to confuse the issue (since it contains outdated info). Cheers, ~Claw

The hatch should be blocked, but isn't. So the kerbal is allowed to eva and the helmet collides with the sci jr. This one was a rough one to balance. There needed to be enough freedom to allow kerbals to eva, without making the hatch check excessive. Unfortunately that means kerbals can sometimes EVA when an part is partially in the way.

@tsaven Actually, if you still happen to have that save, it might be helpful for us so that we can fix this from happening again. For reference, here are the applicable errors. (Might be a missing or uninstalled part.) Cheers, ~Claw NullReferenceException: Object reference not set to an instance of an object at ProtoPartSnapshot..ctor (.ConfigNode node, .ProtoVessel protoVessel, .Game st) [0x00000] in <filename unknown>:0 at ProtoVessel..ctor (.ConfigNode node, .Game st) [0x00000] in <filename unknown>:0 at FlightState..ctor (.ConfigNode rootNode, .Game game) [0x00000] in <filename unknown>:0 at Game..ctor (.ConfigNode root) [0x00000] in <filename unknown>:0 at GamePersistence.LoadGameCfg (.ConfigNode node, System.String saveName, Boolean nullIfIncompatible, Boolean suppressIncompatibleMessage) [0x00000] in <filename unknown>:0 at GamePersistence.LoadGame (System.String filename, System.String saveFolder, Boolean nullIfIncompatible, Boolean suppressIncompatibleMessage) [0x00000] in <filename unknown>:0 at LoadGameDialog.PersistentLoadGame () [0x00000] in <filename unknown>:0 at LoadGameDialog.Create (.FinishedCallback onDismiss, System.String directory, Boolean persistent, .UISkinDef skin) [0x00000] in <filename unknown>:0 at MainMenu.LoadGame () [0x00000] in <filename unknown>:0 at TextButton3D+<OnMouseTap>c__IteratorA8.MoveNext () [0x00000] in <filename unknown>:0 (Filename: Line: -1) [UIApp] OnDestroy: MessageSystem (Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64) NullReferenceException at (wrapper managed-to-native) UnityEngine.Component:get_transform () at KSP.UI.Screens.ApplicationLauncher.GetModListSize () [0x00000] in <filename unknown>:0 at KSP.UI.Screens.ApplicationLauncher.ScaleModList () [0x00000] in <filename unknown>:0 at KSP.UI.Screens.ApplicationLauncher.RemoveApplication (KSP.UI.Screens.ApplicationLauncherButton button) [0x00000] in <filename unknown>:0 at KSP.UI.Screens.UIApp.OnDestroy () [0x00000] in <filename unknown>:0

The triangular light actually indicates what sort of recoverable state you are in. If it's blue, you can return to the space center. If it's green, you can recover the vessel. If it's orange-ish, then you're usually close to being able to leave the vessel, but it might still be moving a bit. If it's unlit, then you can't leave (but might be able to revert).

The logic was different for 1.0.5. It used to be that the craft had to be suborbital and inside the atmosphere to count as flying. The check for "Flying" is now done before the check for suborbital state.

This is the most comprehensive information I've seen to date. Thank you very much for that! I've actually been trying your Kerbal1-5 "drag the srb" for a while here and I'm still not hitting any issues. I've sped my processor up and slowed it down with no change. Mostly been in x64, but getting ready to switch to 32-bit next. I've also been watching the in-game perf monitor, without noticing any particular change. What's your vsync set to? Every frame, or every other?

I've already put a toggle in there that allows you to flip direction individually. So you can place via symmetry and toggle them the way you'd like.

Try removing the OpenGL flag and see if that fixes it.

Well, it shouldn't be too wobbly if you strut it in triangles, and run those triangles along the axis of the ship. Though it'll depend on what the three modules look like, that you are connecting. Try to keep everything axial and somewhat flat (rather than the long, slender things you see in sci-fi shows). When things get long, you'll definitely get wobble on the connecting joints, even if you strut. If you have struts connecting the width of the vessel (such as the fuel tanks) down to a part that the docking port is attached to, that will help a lot. I would recommend putting some torque wheels or RCS ports on those engine nacelles too, or it's going to bend like crazy when you try to turn it. Also, you may want to consider launching that thing empty and fueling it up in orbit. Trying to launch something that large, constructed as a hub and spoke, while full of fuel will probably be quite a challenge.

You don't see them. So I suppose in that sense, they are magically added. They're there to help prevent having to jump through hoops to attach payload to the fairing, since the fairing itself can't be attached to. As 5thHorseman noted, they were broken for a bit, but should (hopefully) be working now. I do recall reading some reports of mixed results, but that might be from back when they weren't working as well.

I believe it was recently changed. If you are in-atmosphere (and not landed or splashed), then it's "Flying."

As Jarin indicates, the "mod" key actually refers to the "Modifier" key. The wiki page also lists what the Modifier key is for each Operating System. Windows is ALT, Mac is Option, and Linux is Right-Shift. So hold down the modifier key, and press the desired WASDQE key to trim in a particular direction. Please note that if SAS is on, you can trim the craft, but SAS will override any trim input. Cheers, ~Claw

Well, the body lift fix only forces the game to reload the body lift. It's really not doing any fiddling behind telling the game "hey, you forgot to load this." But aside from that, I agree that the lift lines are looking waaaay off. Is that landing gear the root of the craft? (I ask because the root of the craft has some special considerations for drag cubes.) Also, that's looking like all stock parts. Can you upload the craft?

I've done this a bunch. So much so, that I didn't bother to count. What else does your ship look like? I've been doing this with a pretty simple ship, though I did fiddle with the staging a bunch on something like the KerbalX. Your log looks like there's only 30ish parts.The errors thrown are also not consistent with the other reports, but still might be something worth investigating (though might not be related).

I removed that option in the most recent release. It was causing some issues for a few folks, so I've removed it for the time being. That's actually backwards from what I usually hear. Not the exploding part...but that kerbals usually ragdoll when touching a leg or wheel. We are looking at the wheels and landing legs. Unfortunately it's looking like a unity upgrade will be needed. There were some fundamental changes to the way PhysX and Unity handle wheels, and the downside is that they are a bit less flexible than they used to be. Possibly. I'll have to add that to the list of things to look into. Please do let me know if you track it down. I certainly don't want to be causing any crashes.

This isn't really aimed at anyone in particular. Just trying to address some of the questions. Three weeks. And I/we can't fix anything if we don't know what you're referring to. I'm not trying to blow smoke up anyone's anything. I WANT to fix bugs. I have been trying to fix bugs as a player of this game for a couple years now, and I try to fix them from the inside also. Sending up flares that "squad doesn't care" is only frustrating from the sense that it is impossible to please everyone all of the time. Sal isn't trying to deflect blame, but is trying to point out that if we track down the bug to a fault in Unity, then we can't fix that bug directly. We can, however, try to work around it, as we have done on numerous occasions (the fairings contain one such workaround that took quite some time to develop). But we can't even attempt to do that if there is zero information provided. So that folks know, the three week vacation was because several of the developers haven't had a vacation day in nearly a year. They worked through December holidays, and beyond. Half of the team could have gone on vacation, but then when the first group came back, they'd have to swap places. With such a small team, that would have left everything pretty minimally staffed for at least a month and a half (which is also less than ideal). That also isn't very conducive to productivity, and just leaves those who are not on vacation right back into the "not enough people and too much to do" situation. It's a fine line to be had, between working people endlessly and trying to actually release something. We haven't. And we keep saying that. Unity 5 is virtually a brand new engine. With it, we are finding many new issues with code that used to be rock solid. It takes a while to track down where the issues are, and it's not always clear if it's KSP interacting with Unity, or Unity itself. Also (FYI), forum moderators are game players and forum visitors like virtually everyone else here. They aren't privy to any "inside" information, nor are they squad employees. The prerelase was on steam because of the massive amount of data push that was needed. The KSP patcher simply doesn't work. It's being worked on, but it wasn't working for prerelase. The KSP store was not set to handle that sort of data demand. Because of the massive overhaul KSP 1.1 needed, the prerelease was extremely helpful in diagnosing and fixing numerous problems that weren't seen in Experimentals. I agree that it was highly unfortunate that 1.1 couldn't prerelease on the KSP store...but for reals, it wasn't done out of "Steam Exclusiveness." It's not, but if the only info we have is "developing memory leak," it's really, really hard to diagnose. That's cool too. Though I only have so much oil in my can. It's hard to squirt some on the squeak if I don't know where it's coming from. Kerbonauts, we really do care. I'm not sure how to actually express that. We do read the forums, even if we don't reply to everything. Cheers, ~Claw

Also, provide a .craft or whatever you were doing. No detail is to small for an issue like this. For example, turns out there used to be a memory leak (and causing big lag) when setting engine tweakables to a certain percentage.

We are aware of font scaling issues. There's no need to attack each other because of font size or post dates.

Yep, it sure is. So long as your vessel is kerballed (at least one) for the whole circumnavigation (rule #2). Good luck!

Ha, I was trying to reply on my mobile and it wasn't letting me. And no, but I will call @AmpsterMan

This particular warn/error has been around a while. These show up sometimes when the focus is away from KSP. Personally this warning hasn't caused me any troubles, but some people have reported crashes from it. Though I think it's coincidental to something else. That's good to hear. It used to be pretty common for us to suggest that people clean out their machines. 1.1 (with Unity 5) seems to be even more stressing to some hardware. Though there are also some graphics corruption issues with OSX, I'm glad to hear you were able to solve your issues. This seems to be the most common place, so certainly the first that I'm looking at. But I personally have no issues in the VAB or SPH, so I'm hoping to narrow it down even more. Even if it means using an add-on or two to do it. Yeah, this seems to be the extent of the information so far. Totally random, and not tied to anything in particular. Thanks for posting kerbonauts. I am reading, and trying to gather as much info as possible. Cheers, ~Claw

I'm not sure off hand, I'd have to take a look. It might be in a spot of code that's hard to change via add-on. I think so. There's actually quite a few options available for docking ports that can be turned into tweakables.

That seems like a valid hypothesis. The thing that gives me pause is the fact that some folks are having no problems at all. So I'd still like to track down what's different or why some people are running into this with high frequency while others don't seem to experience it. The latter implies there might be a way to work around it in the mean time. We're also aware that there are some unity updates that we'd like to investigate for upgrading. But since the team has been scattered on vacation, there's no significant news to report.