Claw

Indeed, and moved. Cheers, -Claw

This is looking fantastic! I really hope the final two ends connect for you (at least well enough). Good luck! I believe he said he used surface mounted cubic struts, then attached the Mk2 segments to those. Cheers, -Claw

You know?... I think this same thing. But that's actually part of the reason I created this challenge. I am interested in seeing other people's approaches to the same scenario, and I was curious about some sort of orbital drop pod system. With biomes hopefully coming soon, I suspect we'll see a larger variety in biome collecting craft. Cheers, -Claw

You are quite welcome! It's incredibly helpful when people can narrow it down like you did. Thanks for the point out. I'll have a deeper look at it soon, but it looks like something I can add to the front page. Cheers, -Claw

Depends on what version you are using. Massless parts are now correctly accounted for the the SPH/VAB. Landing gear shouldn't move the CoM around in the editor anymore. They used to be handled differently, but they've been set up the same as the other physicsless parts. (or unless you're using mods?) Gear were never different extended or retracted. Although your solution holds true for earlier versions of KSP. Cheers, ~Claw

Yep, http://imgur.com is great because you don't need an account, and it'll let you set up albums (which are pretty nice to embed on the forums). It will also let you upload a single picture and link to that, if that's all you want. Cheers, ~Claw

No worries. I think maybe I'm coming off a bit rude, and that isn't my intent. I was also typing fairly quickly and trying to make sense at the same time. So my apologies as well. I suppose I'm trying to say that it's not that I don't believe you, I just can't imagine why it would be reacting this way. Also, I quickly tried out what you said and didn't get the same results (but it was an admittedly short test). However, after all the time I've spent in this game I'm learning that I can't just discount (or even believe) anything until it's really investigated it. Cheers, ~Claw

Sounds like most of your questions have been answered except his one... Starman4308 said it's highly improbable, but I'm pretty sure it's flat out impossible. Most of the high end players have tried making a Dyson ring at some point. There are several game engine limitations to this. The biggest problem is that the ring literally rips itself apart with floating point inaccuracies after the vessel gets big enough. Not to mention running into memory problems. All that aside, the massive phyiscs burden on the CPU would also make it likely impossible to assemble. Eventually it would take minutes (or more) per frame to render, making docking pretty much impossible. If you did somehow overcome all this, you would eventually have to break your "stock only" rule because once it got big enough, you wouldn't be able to get to the end of the vessel to dock more parts. The game has a physics bubble of roughly 2.5km. Anything outside that isn't rendered. That means if the craft's reference point is more than 2.5 km from the end that needs more parts docked to it, the craft will not load as you approach for docking. The only reason people don't say that "it's definitely impossible" is because we don't want to give up hope. But practicalities make it highly improbable. Cheers, -Claw

I think Red Iron Crown has your answer. A kerbal on EVA cannot transmit on his own. You need to either store the science in the pod by right clicking on it and selecting "store," or get back in the capsule. You can then transmit the science later by right clicking on the pod and reviewing data (you need a probe core or kerbal on board). Be careful about transmitting science from pods. You can end up sending all of it, including surface samples, if you aren't careful. If that isn't what you wanted to do, it would result in lost science (because some experiments have a transmission cap). Cheers, -Claw

I think I understand what you mean. I'm just saying that the way the code flows for generating/consuming resources and how craft files are saved makes this behavior unexplainable. But like I said before, it's still possible. There are lots of little weird things like this in the code. Maybe the game reorders the parts on launch, although I've never seen evidence in persistence files where action groups affect the parts sequence. Like The Rocketeer said, more testing! Cheers, -Claw

With v0.25, you can give yourself some starter science, rep, and funds. When you start a new game, click on the difficulty button and select your previous difficulty. This will set up all the multiplier levels and other basic options to what you had before (or whatever you want now). Then click on the Custom tab. At the bottom left there are sliders where you can adjust the starting funds, science, and rep. You'll have to know roughly how much science you need to unlock the tree to the point you were at before. After that, start up your new game. Now you can unlock the tree up to where you were. Also, you can copy your craft files over from your previous save by copying from the KSP/Saves/SaveName/Ships/VAB or SPH directories into your new save. Cheers, -Claw

So the reason why placement matters is because the entire craft is a long list of parts. Each part is processed in what is essentially the order in which it was placed. The game runs through this list and runs each piece of code associated with the part. So for intakes, they generate air. For engines, they consume resources and generate thrust. At some point, the engines are asking for more air than what's available. One engine will ask for air and the entire ship will be depleted. No more air is available until the next time an intake is processed. So, if you place all your intakes first, then the engines, you are guaranteed to starve the last engine of air because no more air is generated before the engines down the line are processed. However, if you place some intakes, then an engine, then more intakes, then an engine, the air generation/consumption process is interwoven. So the first set of intakes generate some air, then the first engine consumes it all. The second set of intakes generate air, then the second engine consumes it, and so on. Action groups do not reorder parts. You can assign action groups during build, or after you're done. It doesn't alter part order. I would say it's possible that on your run where the engines were on a higher action group, the game just happen to be in a position where the intake air resources were different than on your other runs. In that case, it might have just been coincidental that you got asymmetric flameout. All that being said, I also wouldn't completely discount that this is possible (as weird things do happen in this game). But it's just not normally mechanized to respond to action groups like that. Not sure if that helps. Cheers, ~Claw

If you are using my stock bugfix modules, click here for the current version. I fixed my modules for compatibility with other mods. The problem is more rooted in the libraries in use by many mods. My mod was causing KJR and Kerbquake to trigger one of these deeper bugs. So give my stock bugfix modules a fresh download and see if that helps out. http://forum.kerbalspaceprogram.com/threads/97285-0-25-Stock-Bug-Fix-Modules-%28Release-v0-1-5c-10-Dec-14%29 Hopefully that'll sort it all out. Cheers, ~Claw

v0.1.5c is now out. It includes a fix to make AnchoredDecouplerFix play nicely with Kerbquake (and a few other mods). This fixes the problem where staging decouplers would only come off one at a time. Exceptional thanks to MartGonzo for narrowing down the mod combination and posting relevant logs! Cheers, ~Claw

Hmm. Actually you may have helped me narrow this down a lot. I have a feeling I know what's going on based on this off of the Kerbquake thread: I'll put out an update tonight that I'm guessing will fix it. If my guess is right, it's a Kerbquake problem, but induced by my mod. Cheers, ~Claw Edit: I've verified that KJR is not involved with this. It's something with Kerbquake and the Stock Bugfix Modules.

I agree with Laie. For pure looks I like the first version. If stability on ascent is your problem, you can attach some wings/fins/control surfaces to the bottom of the craft to offset it. I'm guessing that as soon as you start to gravity turn (or the flight path drifts at all) that it flips over. Fins on the bottom would help fix that, but obviously adds cost, etc. However, great job on both versions! Can't wait to see the final results. Cheers, ~Claw

You can also check the thread below, which will point you at the log files. Posting one of those can help us get a better idea of what your issue might be. http://forum.kerbalspaceprogram.com/threads/92230-Stock-Support-Bug-Reporting-Guide Welcome to the forums! ~Claw

I was going to suggest something like this, assuming you wanted to stay stock. I've done it before, but it can be really aggravating for large structures. Sometimes those lock & key setups need a lot of precision to get lined up which can be a pain when maneuvering large components. When I use the lock & key, I attach them with the structural pylons. When you detach the structural pylons, they don't leave anything behind. Also, if you didn't know, you can get the components docked together and quicksave. Then undock them, keeping the docking ports very close together, and make fine tune adjustments. Then do another quicksave (probably with ALT+F5) and quickload. Doing that will reset the ports and they will snap back together without having to get too far apart. I've managed to get 0.0 rotation in the save files using this technique. By the way, that looks like it will be awesome when complete. I don't think I've seen the MK2 parts used like that yet. Good luck! ~Claw

Fantastic! I'm glad to hear it's still working. I am working on a fix module for this (link to other stock bug fixes in my sig). The problem with this one is detecting when the bug exists. It can be difficult to tell if the ship is actually connected when the port thinks it isn't, and to check if there isn't something connected when the port thinks there is. It would be bad to go around resetting ports that don't need to be reset... I'm working on another project at the moment, but this fix is still in the queue. (Hopefully someday "soon.) I'm not sure which "scene changer" crash you're referring to, but there is a known bug that prevents quicksave or returning to the space center. The known one isn't a "kraken" though. The name kraken gets thrown around a lot, even though the actual kraken was slain a while ago. So I'm not actually sure if you're referring to the known bug or something else. Cheers, ~Claw

How did this get missed?... Dreaddy, Are you still having problems? If you originally purchased the game via the store, then log back into your accoung. You'll be able to go to "my account" and download from there. If you purchased from steam, try verifying your game cache (I think that's what it's called). If that doesn't work, you can move your KSP directory and try it again. Cheers, -Claw

I have to say, thank you guys for working together to try and figure this out. If more people did this with the really hard to track down bugs, I think more of this kind of stuff would get figured out (and maybe fixed) faster. Please, keep up the good work! Cheers, -Claw

Indeed. Moved to modded support. Also, have a look through this thread. It'll tell you what kind of info will help us help you. Welcome to the forums! -Claw

This is looking nice! Good luck, and I can't wait to see how it turns out.

One thing to try off hand while we're waiting for your crash logs. Open your settings.cfg with a plain text editor (like notepad). Search for the line "TEXTURE_QUALITY". Change the line to read "TEXTURE_QUALITY = 1" (or even try 2 or 3). Save it and restart KSP. It might not be this, but it's been a common thing with 0.25. KSP makes a huge memory grab on some scene changes which has been causing a variety of problems for some computers. Welcome to the forums! Cheers, ~Claw

I've been trying to replicate this and haven't been successful. I do see that with KW Rocketry, TE reports negative values for KW rocketry parts (which makes sense because they are negative). When I am running TE and my fixes only, I do not see any negative values with TE. And I don't see TE reporting any values "in flight." In no case did I run into staging problems. After looking at it, I think KWR is using negative values for some specific purpose. In that case, I don't want to blindly fix the negative value because I'm not currently seeing any problems. If people are still having decoupler issues, please post logs and more details about other mods. I'm not seeing a problem with KW rocketry or TE. Cheers, ~Claw