pincushionman

If you have a hatch there you don't need an extra feature. Though the problem isn't usually (lt least for me) aligning the the ship with the camera, it's in aligning the camera with the planet. Knowing how the navball works helps a lot, but having a camera snap-to-direction would be a great boon. The "project navball on the screen" mods help with this, though.

What it boils down to is in the particular version of Unity upon which KSP 1.1 is built, the implementation of PhysX wheels is flawed (and KSP is not the only game affected). All the 1.1.X patches have mucked around with settings to alleviate the problems, but can't resolve the root cause without a newer Unity minor update and wheel middleware package (which is coming in 1.2). A screenshot probably won't tell you much, but this leads to landing legs being unable to keep landed craft from sliding on an incline, or causing airplanes to spin out on takeoff or landing. And it's extremely sensitive to exact configuration of parts as to whether it happens or not. Some people have worked it out in their designs, others have a great deal of trouble. I myself recently turned an otherwise well-behaved airplane into a steaming pile of brokenness by changing from one engine on top to to two on the sides. If you're happy still using 1.0, at this point there's no harm in sitting back and waiting for 1.2 to drop. Better yet, though, you can download the current version and keep the 1.0 and 1.1 installs separate; then you can try out the new version without fear of losing the good 1.0 install you already have.

I'd like to point out that ships despawning at >1% atmosphere pressure while not in focus isn't "an issue to be resolved," it was a deliberate design decision. Aerodynamics calculations are costly, and calculating for what is almost always discarded stages frees the calculation for what's actually important - the active vessel. Now, in 1.1, the constraints that drove this decision are less severe - individual vessels can have their own physics threads, and there has been a general improvement in performance. So it may not be out of the question to re-think this, at least for items that require no control, like those with parachutes.

If you have a desktop or tower, you also may want to re-seat your CPU heat exchanger with new thermal paste, or replace it with a better (aftermarket) one. But…cents before dollars. First thing to check is whether the CPU (not case) fan and heatsink are clean, or they don't do any good. if that doesn't work, pop the heatsink off, clean both surfaces, and replace with new thermal compound. If the old stuff is cracked or loosened it won't transfer heat well (and if you've pulled them apart to check that, you're committed). If it's still not good enough, your heat exchanger may not be up to snuff. Older heatsinks are basically a block of metal with vanes on it; better ones use a heat pipe to the block, separated from the CPU. You'll know what type you have when you see it (if there's a metal tube, it's a heat pipe). But since money's an issue, try the first two first. Cleaning is nearly free, and thermal vompound is only a few bucks. Heat exchangers are't exactly cheap, but they're a hell of a lot less than a new CPU. And if you can play in the basement, play in the basement. This has nothing to do with the technical suggestions.

The old forum sofware had prefixes, didn't it, RIC? We do have tags, which would suffice, but people would need to remember they're there. If the new software supports prefixes it would be a better solution since they can be required.

Does it work on any games on your current OS? And what do you mean by "try to bind…it doesn't work"? You're in thr Settings menu on the right-hand side, manually binding individual axes, right?

Even if you don't use transfer your account to Steam (and that's presuming you even can do that), you can still launch the game through Steam via "install non-Steam game." You don't get cards (which are kinda worthless), the news feed (which is certainly not better than the forums), or the second screenshot key that conflicts with the deb-…heywaitaminit.

Wow, I'm late to this party. Short answer: Yes. Long answer: No. Wait what? Not yet. First, time needs to be made a proper resource (because it sure as hell will be with LS), and the game balanced around that. We need the absurd building-upgrade and kerbal-hiring costs reduced to something manageable, with a monthly cost based on building state and number of kerbonauts added to the pie. This gives us a framework to add in time-based mechanics like construction time, long-duration experiments, and, yes, life support. Right now the kerbonaut-replacement cost is too high a burden. This also allows the main difference between difficulty levels to be life-support and communication limits rather than upgrade costs, making harder actually harder, instead of more grindy. Second, it needs to be simple, like Snacks! Or USI-LS. One generic resource that gets used; one generic "waste" that can potentially be stored, recycled if your tech is good enough, or ditched. Anything more would be more micromanagey than I'd like. Bigger living/activity spaces can be abstracted by having those parts contain disproportionately more LS resource. But most importantly, we need better mission-planning tools. We need an orrerry where we can build missions given starting/target bodies and start times, and it will spit out the required dV and transit time estimates for that leg. Then you add wait/loiter times and chain them together. Then we need decent dV info in the VAB and in-flight. Otherwise many new users (and let's be honest, many old ones too) will not know how many lunches to pack. We need these tools first. Not least because we need these tools anyway.

No. He's saying you can set the chutes so thst they "arm" when you hit the staging button, but don't "deploy" until pressure conditions are met. That's kind of what had already happened to you; they "armed" while still in space, and their "deploy" pressure was set too low so it happened while you were still too high and going too fast. That's why they didn't tear off before you got to 20 km or so.

Don't asteroids spawn in the vicinity of Dres too? I thought that was still a thing. You might need to do something (like encounter Dres in a ship) to prime it, though. Or maybe we need to wait for the Asteroid Day mod to update with it's MOAR ASTEROIDS code. (The official mod, by the way)

what

What I'd rather see, instead of putting up satellites that have specific "normal" parts requirements, have requirements to place this specific satellite bus there. Which you're given as a subassembly. That you can't edit. Maybe even use a library of new part models that aren't even in our normal parts lists, representing customer-specific hardware, but in game terms being dead payload weight. That would add a fair bit of challenge, having to design launchers around arbitrary payloads you have no input into. And some of the payloads could be like cubesats, which are never profitable by themselves, they always have to be piggyback payloads, but at least they make it easy to actually do the piggybacking.

The reason is twofold, really. First, the REALLY hard stuff in rocket design - the nozzle design, pumps and plumbing, durability and reliability, multiple restarts, fuel boil-off, those kinds of details, are abstracted away or not present at all. The small scale and lack of life-support requirements doesn't hurt either. Second, planes benefit less from these abstractions than do rockets. But while even the most advanced rockets are more or less cylindrical tubes with an emphasis on drag, airplanes are highly shape-dependent and are slaves to all aspects of aerodynamics. And the simplified flight model of KSP is, at best, adequate for flight. FAR helps, but there are still limitations. Parts are heavy. The small scale and overpowered rockets means rockets suffer less. The LEGO wings don't actually aggregate into large wings so we don't get drag occlusion or aspect ratio or wing sweep advantages. We can't play with the airfoil shapes. We don't have the freedom to put fuel in places that would let us easily balance. We don't have a good way to evaluate drag. Wheels are still borked. And the joints. Aren't. Stiff. Enough. What it really boils down to, though, is the tools we are given are great for dealing with the problems that the game presents us in rockets, but are only pretty okay for dealing with aircraft design problems. Which is okay, to be quite honest.

…why are you trying to turn with your rudder?! You want to turn by applying roll.* In theory many planes can be flown without considering the rudder at all. It's just uncomfortable as hell. And not very safe. * this is, admittedly, super non-intuitive

I think we all need to take a deep breath here. Definitely us PC players do. I can say with confidence that most of us aren't really aware of what problems are really breaking the console players' experience. I know this is the first I've seen of this savegame-not-working thing, but that is a very serious thing indeed. Now, there are complications discussing this console port issue. Because it's not so clear what the process is for anything. We've all become familiar with how SQUAD handles its releases on its website and with Steam; we've been through it and SQUAD has always been pretty open and transparent about it. But remember they changed their process at about…oh, 0.90 or so, and we were all pretty…unhappy about that too. But this is different. SQUAD does not own this release and update process. It is Flying Tiger's responsibility to manage it. And if there are bugs in their releases (that are NOT present in the PC versions), then it is bugs in their code, not SQUAD's. Maybe. Maybe there's something about SQUAD's save files that the consoles don't like. But that doesn't make any sense. On PC, they're just glorified XML-kinda text, there should be no issue reading or writing that. So maybe it's FTE's code not handling the file read/write to the console file system correctly. But that doesn't make sense either, since Unity should be offering an abstraction that just works. And while SQUAD has a strong incentive to get it fixed, if it's indeed FTE code or a Unity issue, it's not clear whether SQUAD has the ability - or authority - to actually implement the change. We don't know the details of the relationship between SQUAD and FTE. And even when a fix is made, it's not so clear how quickly it can be implemented, given that it's a process owned by yet another third party (the consoles). So…TLDR…I don't know what to think about this.

You can also angle your rockets out so they fire around the asteroid. Your separator can be significantly shorter that way. This introduces cosine losses, yes, but cosine losses >> blocked exhaust.

How little does a motor need to contribute to be a "rocket"? Hate to be a naysayer here, but if only three rockets contributedto the lift and four provided spin…then you only had seven motors on your rocket.

Well, that's certainly the info I was looking for. I can justify $150 worth of graphics cards, but another $300 or more on top of that in processors and mobo (that in particular would have been a pain in the butt) is a little tough to stomach, especially if the current CPU is not that bad. I haven't really taxed it in any of my KSP builds, but in other threads where CPU power was discussed, the consensus was that the 955 is perfectly adequate.

Okay, I'm looking at upgrading my current rig with a new graphics card. I was interested in NMS and Elite: Dangerous, but canirunit indicates I need a grapics card upgrade (I believe shader model or supported DirectX version is the problem here). Unfortunately, it doesn't look to be as simple as getting a new card. I have a Geforce 9800 GTX+ card, which is a PCI Express x16 2.0 card, and got a MSI NF980-G65 mobo, which has card slots to match. As it turns out, any of the newer cards that are a significant upgrade appear to need PCI-e x16 3.0 instead. It's a 6-year old setup by now. So, basically, I didn't future-proof myself very well with regards to the motherboard. So I'll need a new one. Which means I actually need a new mobo, a new processor, and a new graphics card. Not the kind of money I wanted to spend, but it is what it is at this point. Case, HD, power supply, and RAM appear to be swappable no problem. I don't want to go top-of-the-line power for everything, especially with the graphics card, but I do want to choose a motherboard that I can reasonably expect to find graphics and CPU upgrades for in, say, 4 years. I'm using these charts from Tom's Hardware as guidance: It looks like something like a Geforce GTX 950 is the price range I'm looking for, and it looks like there are many better cards that may be upgrade options later on, in the same interface. It's the motherboard and processor I need some help with the approach. I need a decent processor (I'm thinking an Intel i5) on a newer socket. Does anyone have suggestions on the direction I should take with that in mind? EDIT: Dang it. I had yanked the tables from those pages in spoiler blocks here because TH runs hella slow for me, and I didn't want to put you through that. But it didn't work, so links instead.

Oh, that's a really good idea!

Okay, then, so we're on the same page here. And if the direction matters, then two ends that aren't perfectly in-line can cause coupling between bending and twist. Angle snap would help immensely in reducing that. That or the solution I see in drawing programs where holding shift snaps a drawn line to a cardinal direction. That might be a solution too, but that might be hard to implement in 3D.

When I proposed the "core" concept, the location of the COM thing hadn't happened yet and all airplanes (particularly small and short ones) were notoriously tail-heavy. The engine COM change did help, but as you said it created the whole "fuel-volume" issue. And I understand the realistic problems a long jet pipe would cause, but this is a matter of working around the limitations of the LEGO building model. In real life engine designers have more flexibility in the jet pipe shape and length than we do, but more importantly, airframers have a lot more flexibility in the placement and shape of fuel tanks than we do, too. And a system like this would help keep the number of engine choices manageable, too. I'd rather have a few primary engine cores that get "featured up" with effectors than have to search through a long list of engines that are quite similar to get the same flexibility. There could always be a limitation in the effectors that they must be within X meters of the center of a core, particularly for "nozzle" effectors. But now we're getting more off-topic.

I have been having trouble with that with my current design (trying to strut from one 1.25m tank to another around a TR-18A), but that's not necessarily what I'm worrying about. What I'm encountering is the floppy rocket is twisting under a yaw, which is real bad. In real life, these two configurations are going to behave differently under vertical and side loads: That is, even under just the weight of the upper parts, the one on the right (in real life) will cause a counterclockwise twist when viewed from the top. Not much, and maybe not visible, but in real life things are way, way stiffer than they are in KSP. In KSP, I'm not sure how the extra stiffness of struts is implemented (frankly, I'm not familiar with how stiffness is handled at all). If it's an additional stiffness added between between the centers of the two parts, then it's just visual. But it the locations of the strut ends define the load path, then it does make a difference, and small deviations from the intended direction will have noticeable coupling effects given KSP's unrealistically floppy joints. We're already aware of the differential stiffness bug that causes aircraft to roll slightly when you apply pitch, and contributes to the aircraft-twisting-and-yawing-off-the-runway problem. I've done a little research, and it does seem that the exact placement of the struts along a single part does change the relative stiffness - it involved hanging a pod on the end of a long tank, connected to another tank via a radial attachment point: The deflection was measured by looking at the Pitch value of the right-hand pod in KER. Various strut positions produced different results. But the deflections are so small I'm not sure they're not just random fluctuations. I'd need to come up with a way to up the "gain" on the measurements and isolate them from the entire structure being tilted slightly. What I really need is a reliable way to measure the difference between the orange tank axis and the white tank axis, which I'm not sure we have a tool for. And a lot more tests to determine a trend or not. This is all somewhat unrelated to the circumferential snap problem, since it wouldn't help this setup and this setup isn't as sensitive to twist. But if the placement effect is real, then it's likely real in all directions. I'm willing to take the drag statement at face value, that sounds like the way it would have been done.

Title says it all. I spend a great deal of effort trying to get my struts to line up with one another. I don't know if it has any game mechanics changes for sure, but if the direction of the strut has any bearing on the direction of the force, or if it can change drag, it would be very useful to not have to eyeball the placement of the second end. It would sure make it easier to make it look better, at least. Especially since there is no readily available reference tools like moveable datum planes. I have done some very cursory experiments, and the indication is that the exact placement of the strut does have some bearing on the stiffness between the attached parts. But not detailed enough to know for sure.

…except the parts they're returning don't contribute to space debris since they're never in orbit. Who/where is that quote from? Link?