pincushionman

I only know because the exact same thing happened to me, and I didn't believe the explanation until I bit the bullet and installed KJR. I saw the light and now preach that gospel.

Not really possible. You might get something oldFAR-ish, but the nuStock and nuFAR approaches are about as different as can be. The only way to get nuFAR-like performance is… …install FAR. Whodathunk?

In KSP, there's a long-standing bug that causes stiffness of mirrored parts to be slightly different. Enough so that under a hard pitchup, the wings twist different ammounts, resulting in differential lift, resiuting in roll. The best you can hope to do is reduce this - either add MOAR STRUTS between your wing segments, install the mod Kerbal Joint Reinforcement, or both.

Given how cheap SRBs are any clever solution you can find that works is not going to be significantly less cheap than than the normal way. But here goes: baseline: 2x thumpers = 2 x 850 = 1700 2x TT-38k = 2 x 600 = 1200 total = 2900 proposed solution: 3x thumpers, 2/3 fuel, 2/3 thrust = 3 x 686 = 2058 1x TR-18A = 400 total = 2458 You save a whopping 442 funds.

Well, I have to treat a particular 4-year old like a king today (wait…how is that different from the days that aren't his birthday?). We're still dealing with the aftermath* of that particular prank. *well, strictly speaking I hope I'm "dealing with the aftermath" for a long, long time, but that doesn't mean I won't jokeabout it.

Have you set the deadzone in the input settings? and does the Saitek software allow you to affect the sensitivity curves?

At least they only switched the titles. Everybody probably doesn't even pay attention and just clicks "the link in that place" to go to the appropriate subforum. If they'd switched the actual links it'd be chaos.

I think there's some misunderstanding as to where the complexity is here. Calculating dV is freakishly simple. Tedious, but simple. Implementing it into the editor? Not so much. Why? Because the problem isn't the calculation. The problem is in defining the problem. In our case this is about the staging definition. Thrust and Isp vary with pressure? Fuel flow or engine thrust ambiguity? The game needs to offer reasonable assumptions to the player and communicate those clearly, as well as offer the ability for the player to tell the game "you guessed wrong. Here's what I want." it's similar to what engineers do in the real world. Anyone can do the math right. An engineer's job is to make sure the right math is being done.

Is this a bad thing? Man, it's been ten years since I've used a VCR. Still have one, though.

The second you design to use a nanobot as a building block, you're asking for structural trouble. *EDIT* I see the next guy asking "then what are biological cells?" And all I can say is: specialization. In order to have your structural strength, you need a mechanism to fundamentally change certain individuals permanently, and not all of them will be able to keep their networking, sensing, or ambulatory abilities.

I remember an offhnd comment in a writeup of a recent Squadcast that implied…well, that it wasn't out of the question. But not while the 1.1 effort is still ongoing.

I've "liked" maybe two videos. I don't typically like on Facebook, either. As an ordinary user, I value comments on my posts much more than likes, but I'm sure Youtube and Facebook don't really care what I think. Likes are easy to count.

Yes, but a projectile with half the mass, but moving twice as fast, has the exact same momentum but twice the kinetic energy. That's the kind of system @cantab is describing - smaller projectiles moving very quickly.

I guess that all depends on your preferred zoom level. At 100% on my (1600x1200) monitor, I fit an entire single 8 1/2x11 page vertically, with review, navigation pane, and styles pane vertically, and there's still space to each side. But some people prefer to zoom in. You gotta work how you gotta work.

Pro-/retrogradeaffects the point in the orbit 180 degrees from your current position. (anti-/)radial affects the points 90 degrees behind/ahead of your current position. it is less efficient than a properly-implemented pro-/retrograde burn. But there are uses. A radial component to a circularization burn can save you from a less-than-ideal suborbital trajectory after you've missed apoapsis. Also, if on an impact trajectory with a body and are still a long ways off, a small radial burn may be more effective to nudge your orbit out of the lithosphere, depending where exactly you want it to be.

The thing about weapons with the ability to affect the stuff that's "fair game," and the stuff that belongs to you, is that you are then perfectly capable of affecting everyone else's stuff, too.

*coughstartinsciencemodecough*

Not exactly. Acceleration is the instantaneous change in velocity of your vessel; the second derivative of position with respect to time: a = dV/dt. Detla-V, on the other hand, is a measure of either: (1) the vector difference between two velocity vectors through a point, describing a maneuver to move from one orbit to the other, or (2) the maximum magnitude of such a vector difference that a vessel can achieve. dV = dV. Yes, it's the same dV as in the acceleration equation above. So it's a part of the acceleration. Strictly speaking, though, when we deal with dV we assume a maneuver of zero time. We're describing the result of a change in velocity; not the time evolution of the change itself.

All right, so many of us have watched the 2015/3/24 Squadcast and seen what the current state of the game is re: multithreaded PhysX. As is known, Unity 5's PhysX 3 implementation allows for multiple physics threads. The discussions happening on this board for the past several months have been about whether there was a possibility that single vessels could be spread across threads, and the general consensus was that no, they could not. The squadcast pretty much confirmed this; single vessels are indeed individual threads, and new threads are spawned when vessels undergo separation in the flight scene. It also showed a major problem with this: complete game freeze while the (new) threads are prepared. On KasperVld's not-junk gaming laptop a 650-ish vessel was split into a rocket and launch tower, and took 45 seconds to prepare and spawn the new threads. Another significant freeze of 15 seconds was also encountered on booster separation. Further staging events (what I would call "reasonable" part counts) showed no noticeable freezes. Now, the vessel being shown is pretty excessive, and Kasp is on a laptop. But his laptop is a powerful gaming laptop, and even small freezes during gameplay are quite immersion-breaking. Especially on less-powerful older systems that many of us may have. So - we who are not the developers, how do we think they should approach fixing this, and how can they? I have three different thoughts on the matter, but I'm not really knowledgeable about multithreading, or about Unity/PhysX thread handling in particular. But here goes: Code cleanup. Don't worry guys, it'll get better. Just wait. It could be simply that the current state is running in a non-optimized manner for pre-release, and small things will be done to speed up this simulation step. I don't have high hopes for this, at least for the 1.1 release; after all, they've been workng on the Unity 5 port for nearly a year, and I'd expect low-hanging fruit to be picked by now. But one can always hope. Delay thread splitting. I'm sorry PhysX, I'm kinda busy right now. Vessels are running just fine on a single thread prior to a staging event, and from experience, we know that KSP vessels run just fine on a single thread after staging events, too. It may be possible to prevent PhysX from splitting the objects into separate threads immediately and wait until we have more time to let it happen. Figuring out when that good time is, however, is another problem. But once vessels are in space and no longer thrusting or under atmospheric forces things are much less time-sensitive and we can better afford to be inconvenienced by this. Pre-stage threads for separated vessels. I can see the future. Trust me. The problem with trying to split a single vessel across threads is that information has to be shared in two directions between threads, which is slow and cumbersome. Also, if a vessel can break up in an arbitrary manner, there is no way to predict the best way to split the parts up. However, we have an ace up our sleeve here - the staging list is well-defined. We know which parts will go to which threads beforehand. It may be possible to prepare these threads while the stage prior is active, and only have to copy the state of the appropriate part nodes to them rather than having to stop and wait while the new threads are created from scratch. We don't need to worry about two-way communication for this; the child threads are strictly slaves to the previous stage thread. Ideally we only have to do this for the next staging event if these threads can be created in the background. Now, as I stated before, I know very little about multithreading besides what's been discussed on this forum, and next to nothing about PhysX, so what I'm suggesting may be completely impossible. It's also possible that some of this is already happening and the process is just that slow. But I'd sure like to hear the thoughts of those of you more knowledgeable than me! Because while the vessels I saw in the Squadcast are excessively large and complex, the freezes are a little scary. And if there's anything that can be done to mitigate that, even if it's a little more processor intensive, it would make me very happy. TL;DR: Staging can freeze the game. Can it be fixed? I'd rather have a slowdown than a freeze.

This this this this.

Shouldn't need a toggle, IMHO. It should use the same logic as other events and not split threads while the active vessel is "under acceleration," thrusting or in-atmosphere. That's when a hiccup is most apparent. When we're in orbit or landed these events aren't so time-sensitive and we can put up with it better.

This is a real-life proposal, by the way, and not that far-fetched. It's called a laser broom. *EDIT* Ninja'd. Darn you, Fred!

Probably earlier. Because you're probably getting some of the capture assist from the other star, you need to get the orbit dragged down in relatively short order to avoid ejection by the same. That means close encounters with the various other protoplanetary objects already in the system which, if there are more, happen more often. Your rogue body will have to be very lucky to get most of these interactions to be orbit-closing, but not collisions. You'll have to sacrifice some of your "native" bodies to pull it off.

Key information here. This implies other planets' worth of mass flying around, and giver "early" it is going to be all over the place. Capture chances go up, ejection chances go up, destsbilization chances go up, collision chances go up. Going to be very chaotic.

Not in the case of the galaxy. Keplers laws only apply to isolated systems with concentrated masses, like within a star system. Stars in a galaxy are certainly isolated point masses, but in the large scale it's pretty much a continuous distrubution of mass from edge to edge. So Newtonian (or better yet, GR) explanations are much better models. The star orbits are mostly circular/elliptical (in the large scale), but not Keplerian, and perturbations from neighboring stars are the norm. As for the OP's question, "objects" orbit "the barycenter of the system in question." Every object in the Solar System orbits the SS's center of mass, including the Sun, and mainly because of Jupiter that point isn't actually within the Sun. Does the rest of the galaxy have an effect? Yes, but at the scale of the solar system that's pretty much just noise. Likewise, the Milky Way is isolated enough it can be modeled by itself. Similarly, the entire Local Group is isolated enough to explain the interactions, especially the smaller galaxies that are clearly bound to the combined mass of Milky Way and Andromeda and are clearly orbiting. Beyond that scale, objects are still gravitationally bound, but "orbit" stops being so clearly defined and it becomes more that "things get pushed (pulled) around a little" due to the vast distances, timescales, and speeds.