Claw

[quote name='parameciumkid']SQUAD seems to have every other priority over fixing problems that generally only affect giant space stations.[/QUOTE] That might be a bit dramatic. As I noted above, the replication is unknown. It's hard to track down a bug when the cause is completely unknown, and it happens relatively infrequently. So it becomes a question of how much time to spend tracing a single bug vs. fixing others, or working on content. A bug always feels like the worst bug when it afflicts someone. If it happens frequently to you, then please try to keep note of what's happening. Perhaps you can help find the cause. It took me almost a month of working with a couple other people and poking about to track down a claw bug. And even then, it didn't replicate 100% of the time. That was only one bug, and it took a lot of time. The docking bug is another one of those bugs that is really annoying and known to happen, but the steps are completely elusive. Same with the "crashed into VAB" bug. Bugs that take hours to trigger with unknown steps are just about impossible to squash. Cheers, -Claw

The bug referred to in the OP isn't due to mis-snapping, or inadvertently surface attaching docking ports together. I wish I knew what caused it, because then it would be easier to fix. As it stands, it's one of those bugs that's known to happen, but no idea why or how. So, unfortunately, I don't know what to tell you to avoid it. No, it's not been fixed. And yeah, it's been around a while. Cheers, ~Claw

Hmm, interesting. I know the heat shield adds a little weight, but...yeah...

The second bug involved ripping the ship apart, any other ships that were nearby, and any ships that you visited thereafter. Primarily triggered when you try to go to time warp. It did have situations where the parts would race off out of orbit.

It might be that your "usual" kerballed designs have enough torque to compensate for your build style. Many of the pods have a fairly high torque rating, whereas the probe cores have very low (or none at all). Sounds like after staging off your boosters, there's enough drag up front that your rocket doesn't have the control authority to keep the rocket pointed the right way. Try adding some fins or a bit of torque. Also, having several science bits up top (which is hard to avoid) also adds to the drag at the tip of the rocket. So if this particular rocket has more science bits than your usual rocket, that might be adding to the issue. Also, welcome to the forums! :D Cheers, ~Claw

There is more than one bug at play here. It's hard to explain exactly, because in some ways the overlay is wrong which muddles the important issues. - The location of the vector before jettisoning the fairings is displaying correctly in the sense that this spot is where force is being applied. That's what is causing the rocket instability. - After jettison of the fairing, the location of the vector is no longer correct. It doesn't move until the aero overlay is cycled. In this case, the overlay is incorrect. - There's a third bug, which becomes apparent after jettisoning the fairing. Apparently for parts at the end of a stack that are wider than tall, the lift vector ends up negative. So you'll see in the overlay, the lift vector is pointing opposite of everything else. This is an actual error and not an overlay problem. This problem is an issue with the body lift calculations, and is not isolated to the fairings. You can see it on any part that's wider than tall (such as an FL-T100) that's at the top of a stack with it's top node exposed. (This isn't isn't pictured here, but I think is shown in the other thread.) Hope that's clear enough. Cheers, ~Claw

FYI: The fixes that I created for the claw have since been fixed in KSP v1.0.5. So those bugs that I referred to a few posts up have been fixed in stock. For anyone still using KSP v1.0.4, my fix pack is still available and does include fixes for the claw. Cheers, ~The Claw!

Yes indeed, it's a bug with the CoL on the fairings (as also described here). Unfortunately it's not an edge case, and beware that the aero markers lie to you after jettisoning the fairing (until you cycle the overlay). Not that I like saying "there's a mod for that," but if you aren't opposed to addons, I've fixed this in the latest release of bug fixes. Otherwise the only "workaround" is to not use fairings, or design the craft in such a way as to still be controllable with a lever arm that far up. Cheers, ~Claw

What did I do this time?! Ahem... So no guarantees, but yes...two rather nasty bugs with the claw were found and squished. One was from clawing onto a craft when you are in command of the vessel that's getting grabbed (it would sometimes cause the planet to disappear). The second was induced in a very unusual way. Rather than bore you with details, I'll say that the second one is incredibly (incredibly) difficult to replicate. But when it happens, it's quite catastrophic. So the cause of the second bug was found and fixed, but is particularly difficult to confirm if it's been fully eradicated (since it's so hard to replicate on-demand). Personally I'm fairly confident that it's fixed, Cheers, ~Claw

I'd need to know which pod, and which decoupler (or maybe a picture). Without trying, I think there's an issue if you use too big of a decoupler on top of a pod (i.e. the decoupler hangs off). I think it might stick out into the kerbal collision area, but doesn't trigger the "hatch is blocked" message. If you're not using a bigger decoupler, then I'd still be interested in the setup to see if I can replicate in stock. Also, is this EVA taking place in space? Or is it EVAs anywhere? Awesome, thanks. To add some background to this, all of the StockPlus code was actually integrated into the StockBugFixes pretty much from the start. They were shown as two separate mods, but the StockPlus download consisted of a configuration file that activated the StockPlus code. I switched to a GUI system and altered how the StockPlus activation is controlled, partly because it was causing issues for CKAN users. Auto-updates would run through and overwrite all the individual StockPlus settings (because of how this mod was set up). This was also a problem for manual installs also because people had to manually pick through the folders to make changes. So hopefully this will work much better for everyone, and won't require any more more changes. Cheers, ~Claw

Rhendox, You need to allow shared access for these google docs. We can't read them otherwise. Welcome to the forums! Cheers, ~Claw

For anyone else who stumbles upon this, there is now a fix here: http://forum.kerbalspaceprogram.com/threads/97285 Cheers, ~Claw

Version 1.0.5a.2 Released Additional Update for release 1.0.5a.2: - Set default GimbalRate = ACTIVE for ModuleGimbalPlus. Newly placed engines will have GimbalRate enabled and default speed of 10 when ModuleGimbalPlus is active. - Fixed a stock bug with Procedural Fairings, where the CoL is too far out in front of the fairing (causing extra flippy rockets). - Fixed a bug with the Module Hooking routines in the StockBugFixPlus controller. Cheers, ~Claw

After further investigation, there are three bugs going on here. 1) The location of the body lift line before decoupling the fairing is incorrect. It's applying lift force too far ahead of the fairing (i.e. the overlay is correct). - My StockBugFixes now contain the fix for this in ModuleProceduralFairingFix. (http://forum.kerbalspaceprogram.com/threads/97285) 2) The location of the cyan overlay line after decoupling the fairing is not correct. That is, it's showing the lift too far ahead, but that's an overlay problem. That's not a force position problem. - Fix for this is to simply cycle the overlay after decoupling (I did not include this fix because it seemed wasteful to spend CPU cycles checking for and fixing the overlay). 3) The direction of the body lift after decoupling is incorrect. The overlay is showing the direction that lift is being applied, which is in an incorrect direction (i.e. the overlay direction is correct). - This is not limited to the procedural fairings, but is actually a systemic problem in the body lift algorithms. You can replace the fairing with any part that's wider than it is tall (such as a SAS module, or FL-T100), and the incorrect direction of body lift results. Cheers, ~Claw

Ah, okay. I suppose in my attempt to make things easier, I also made them harder. No, I haven't. I looked through your log and it's full of a lot of errors. The first one is from something called JSI. The ones I see the most are from SkytoneMapper, ConnectedLivingSpace, and FAR. Eventually ActionGroupsExtended looks like it goes crazy and spams out the log in flight. So hard to say exactly which is the issue, but there's definitely a lot of errors going on in there. No idea which might be causing the contracts to disappear. Cheers, ~Claw

I was testing a new heavy lifter design for an upcoming mission. Gravity turned...and gravity won. Here it was before hand. Cheers, ~Claw

No worries. Upgrade when you are ready. And not to worry about the MOD key either. I don't think that's a standard term. Mostly one that is used in KSP. Actually, I've had nothing to do with CKAN. I made a couple minor changes to how StockPlus is set up to try to be more CKAN friendly, but beyond that, someone else has been kind enough to manage the CKAN scripting stuff. I can take a look, but I'm actually pretty unfamiliar since I personally don't use it.. That sounds serious. I will try and take a look today. Cheers, -Claw

Bear in mind, that list is what you have found. There isn't a list of what's available, though I imagine you'll spot the trend.

Quite frankly, it's no more hidden than anything else in this game. There's no "grand list" anywhere yet (it's only been a few days), but there's been a couple threads about this already. And many answers which match the one above. If you're driven to find the hidden stuff, then maybe the motivation there is misguided. The World Firsts and other "hidden stuff" is really just there to give you payoffs while you play. If you're looking for an itemized list of things to check off, that's probably better filled vial the contract system. Otherwise, yeah. Someone will need to start the list.

Thanks. And good luck to you! I find that these trips can be quite frustrating at times, but also quite an adventure. Ah, sorry. I don't mean to undercut you. Though I will say that Dres was one of the most fun bodies I've done so far. With the one notable exception of the phantom explosions. I have no idea what's up there, but I had to stick to the higher terrain to reduce the problems. Hopefully you won't have the same issues. Good luck! Cheers, ~Claw

I believe just one engineer. I'd say it checks for the highest level, but haven't confirmed that myself.

Well, it's only 1 point for declining, but I also get the whole "don't punish the player for lack of interactive tools." The typical response here is to say "go edit the .cfg," but that also feels unsatisfactory. I also don't exactly like the idea of a tweakable GUI, but that's a better step. I more agree with a natural way of the game to track yser preference. Such as tracking a counter (of sorts) that increments when you accept a contract type, and maybe decrements it when you decline a contract type (simplified view). That way, over time, if you ignored or declined something like tourist contracts, the game eventually lowers the frequency of tourist contracts. Maybe not quite to zero, but something very low. And if you kept doing "expand station" contracts, the game would offer more types, and possibly with increasing difficulty/demands.

Sounds like this is a request for a hollow tube part, to utilize the inside for cargo work. In which case, tweaking out fuel from a tank doesn't help, because the part isn't hollow and doesn't shield parts inside. Cheers, -Claw

There isn't an "in game" list. Some of the old contracts were converted to World Firsts, such as "reach XXX alt" or "Reach XXX speed" early contracts. Also, the old "explore XYZ" contracts are also a good example of world firsts (flyby, orbit, land, etc on a given body). There are some others too, but I won't spoil them all. Cheers, -Claw

The Mini is handicapped by excessive heating and a poor production rate, but puts out the same resources.