Tiron

Seriously, has anyone tried Reloading the Scene? Because last time I checked (admittedly back in 0.19 or so), the OX-STATs would repair themselves if the scene was reloaded.

Unless you focus the piece of debris in question while it's in the atmosphere(Less than about 69.2km)...the tracking station has a 'debris' category for a reason. Focused = simulated = drag, even if you can't control what it is you're focusing. Anything within 2.4km or so gets simulated too, in the event you have a cluster of junk. Edit: For the record, the ~20km limit you noticed isn't because the orbit actually deteriorates, it's because anything on rails below that altitude is automatically despawned. This is most visible if you eject something while below that altitude and then get more than 2.4km away from it. It'll disappear the instant it passes out of simulation range. On rails parts do not simulate physics and as such can't collide with anything, including planets. If they weren't despawned, they'd fall through the surface, loop around the center of the planet, and then come flying back up out of it. Note that the 'no physics' means that debris can't hit debris, but this won't protect your active ship: The instant the debris gets within the 2.4km simulation limit, it's taken off rails and regains physics, and thus is perfectly able to smash you flat.

Almost all of the parts ARE optimal for some situation or another, dependent on what the player is going for. Some of them are pretty niche, but there's nearly ALWAYS something they're better at than another part. For example: the Cylindrified RCS tank has the same dry weight as the Size 1 inline tank with 50% higher Monopropellant capacity. The Cylindrified weighs more total because of the greater amount of fuel it starts with. It's also hard to mount just one of the Cylindrified ones without unbalancing your rocket to some degree, so the inline has some merit for overall weight savings, at the cost of a worse mass fraction(monoprop wise, anyway). One thing to keep in mind is that the parts aren't INTENDED to be balanced for Sandbox play, they're intended to be balanced for Career mode play. With no career mode in yet, some of them are bound to be less useful than others. But when the more useful part is farther up the tech tree, or costs too much, those 'lesser' parts will look a whole lot more attractive. Also, bear in mind that the current SAS system is still in testing in many ways (C7 is looking at doing more adjustments on it now he's back), and some of the currently useless SAS parts are probably going to regain a point in the future. Right now, with all the problems the new SAS has, getting those fixed is taking precedence. So yeah, I bet you could name just about any set of parts where one seems to be superior to the other, and I could name some thing the 'inferior' one is actually better at. It might only be cosmetic or reducing part count or something, but hey, those things matter to some people. Except for the Inline Advanced Stabilizer and Avionics Package, which probably will get fixed at some point in the future, and the AV-T1 fin, which I suspect will probably initially be the only available fin in career mode (otherwise it WILL be useless even then, unless it's made cheaper than the Tail Fin).

As he says. It's mostly a memory thing: Once they're outside of about 2.4 KM or so they go 'on rails', and cease to have physics calculations performed on them. This means there's a minimal performance hit, but it still has to be loaded and tracked. The tracking is easy because the orbit is strictly defined, but if you have enough of them it could spike your memory usage beyond the 4GB limit and then you're in crashville.

Try dropping out to space center and then loading back in. This used to fix the OX-STATs if they were 'broken'. They're REALLY fragile, though, and break at the slightest touch. Of anything. At all. A kerbal walking on it will break it.

Six of the small ones might work better in every way...except one. Six parts instead of one, on a part you have to mount in at LEAST pairs? That makes a minimum of 12 engines. That's gonna push the partcount straight to lagville in a hurry. As for the ladder, the yellow one at least does have one feature that can make it more useful than the big one: the container that holds the folded up ladder is much longer on the big ladder. So much so, in fact, that if you try to mount it onto most parts of a Mark 1 cockpit, it clips through the other side. Probably the only part that's completely useless right now is the AV-T1 fin, and that's only because there's a lighter-weight part that otherwise has the exact same stats. There's no other two parts where it's that clear-cut, that I can think of anyway.

It's also the first radial engine ever added to the game, has Isp similar to the Mainsail (added at the same time), and the highest gimbal range of any engine which coupled with its radial placement gives it the strongest control forces of any engine. It also has higher thrust than any other radial engine. So yeah.

And here I was thinking of KSC2 as the Baikonur analogue...

Some things to consider on this subject: The 'Drag Model' is very unfinished and completely unrealistic. It works by multiplying the weight by the 'drag' stat of the part, which is more like a coefficient than an actual amount of drag. There's no accounting for shape or parts being blocked by other parts. The only thing it takes account of are speed, atmospheric pressure, weight, and the drag stat of the parts. This means, for a start, that both of your 'nosecone' setups are presently less efficient than *using no nosecone at all*. You're ADDING drag on top of the additional weight. This isn't the case if you use the FAR mod, but in stock it very much is. That said, the general idea goes a lot further: The new cylindrical radial RCS tanks have the same dry weight as the size 1 inline tank, but holds half again as much monopropellant. This means two cylindrical radial tanks hold as much monopropellant as three inline tanks, for the dry weight of only two inline tanks. The Delta-Deluxe winglets provide more lift than the AV-R8s for the same weight and drag (although possibly weaker control force, I'm not sure). The Canards provide stronger control forces, for twice the weight and twice the drag. The Ram Air Intake provides more intakeair than any other intake, and is tied for the lightest (which should negate its higher drag coefficient), and has the same cap on the extra drag as all the rest of them (it just gets there faster, but if you're hitting the super to hyper sonic regime they ALL get there anyway). The AV-T1 has more than twice the weight (and thus drag) as the Tail Fin, for the same effect. The list goes on and on. But as one of my friends points you, you have to remember there are other balancing factors here we don't have yet. In Career mode, you're not just going to be able to use every part. You'll have to worry about things like how much the parts cost, if you have the tech that allows you to use them, etc. Career mode being one of the primary design goals right from the start, you have to keep in mind that it's been planned for since the beginning. Yes, there's parts that seem to be useless, but if it was what you had available, or all you could afford, you'd use it. That's going to come up, eventually, and make some of these 'useless' parts a lot more useful. Edit: It's the lightest and lowest drag radially attachable cylindrical part, and as such is absolutely ideal for providing non-fuel-carrying mounting points for engines and air intakes, with the advantage that it provides a mounting point for both simultaneously. The air-intake version provides very little intakeair but STILL gets drag-capped at speed, thus adding a lot of drag for very little benefit.

You can avoid camera confusion by using the 'change camera' button (Default: v) to go into chase mode: This causes the camera to orient so that up-down-left-right for your craft are all correct relative to the camera, making moving in the right direction easier. It also causes the camera to move with your craft, which can be a bit motion sickness inducing at times, so be careful! Rather than going to the space center, you can use the 'cycle backward/forward through active vessels' buttons, default [ and ]. This only works within close range. Going to the space center has the advantage of packing the ships up and then unpacking them, which stops any rotations, but you can do that just by blipping up to 5x time warp for a fraction of a second. His control notes are for 'Staging Mode': IJKL are the defaults for the translation controls in Staging mode, which can be easier to use than swapping WASD between translation and rotation in docking mode. Note he's kinda half left two keys out, however: In staging mode, H uses RCS to translate forward, and N uses RCS to translate backward. It's frequently far easier while docking to use this rather than primary engine thrust for small directional adjustments. You can switch into 'fine control' mode (default: caps lock) also: It's apparently now set up so that fine control mode will use the same logic the SAS uses in determining which thrusters to use. So fine control mode can potentially REALLY cut down on Monopropellant usage by using only the best thrusters. I don't have a lot of experience with it yet, but people are already swearing by it. You can tell if you're in fine or instant control mode by the color of the arrows on the Pitch/Roll/Yaw indicators in the bottom left corner of the screen: They're yellow in instant mode and blue in fine mode. The key thing, in all phases, is PATIENCE. There's no friction, so your inertia will continue to carry you indefinitely, no matter how slowly you're moving. It's an excellent idea to take advantage of this by using slow movements rather than fast ones. Slower movements are easier to stop and easier to correct, with less change of overshoot (and less overshoot if you manage it anyway. It DOES happen.) It also uses less fuel both to initiate and to stop. Just being patient and taking it slowly and carefully will save you a lot of fuel and frustration.

It's very different IRL. For one, no super powerful magnetic attraction between ports. For two, the ports aren't genderless: There's male and female ends. There's SOME wiggle room built in, but you have to get the alignment far, far closer to perfect in order to successfully dock than you do in KSP. Which isn't as hard as you might think, if you're careful. Hell, the *Russians* made an auto-docking system.

Mechjeb's landing module also features realtime, accurate aerobraking prediction. If you hit the 'show landing prediction' button, that activates the re-entry simulation feature. If the simulation indicates you're going to re-enter and land, it indicates where (or times out if it's a really shallow trajectory). If you're going to rise up out of the atmosphere afterwards, it instead shows the predicted orbit that will result after one pass (and can even set up a maneuver node for the aerobrake!) I also saw that someone did some kind of external aerobraking calculator, but so far as I know only Mechjeb's landing module can do it ingame, in real time.

Both the VAB and SPH automatically save the most recently launched craft. It's listed as 'Auto-Saved Craft' in whichever you launched it from(they each have an auto-save that's separate from the other's). If you've launched something else from that same hangar since, it will have been overwritten. If you haven't, it's sitting there, saved, waiting...

A switch would require completely redoing everything from scratch, more or less, so it's already too late for that. A 'fix' requires that someone recode it in a way that allows the physics to be multithreaded. Ideally, the fix for that would also clear up some of the numeric imprecision problems it has trying to deal with the huge numbers involved (despite the Kerbol system being tremendously size compressed), which would clear up all kinds of minor physics glitches we run into.

A couple of my friends swear by it, but I've never used it. Although the fairly new 'Docking Alignment Indicator' mod looks like it may be best of all, since it just adds new UI elements to help you line up the ports without requiring any new parts. Apparently it's even able to indicate relative rotation, so it might be an absolute godsend if you're trying to be precise. Another possible alternative is to use KAS instead, although this won't work for all situations. KAS connections are a bit floppy even when 'locked', so for structural assembly it's terrible. But if you're just refueling say, there are some theoretical advantages (which I've honestly never tested myself, fair warning.) For a start, almost all the weight is concentrated on the winch side: a non-detachable radial connector port only weighs 0.0075t, less than half what a Clamp-o-Tron Jr weighs(0.02t). The winch weighs 0.1t (the same a shielded Clamp-o-Tron, or two regular Clamp-o-Trons), and the connector is another 0.0075t, so the total weight of a KAS dock including all parts on both sides is 0.115, so it's a little heavier than a stock dock. But again, it does concentrate almost all the weight on one side, which is a huge advantage for say, an SSTO spaceplane. It also doesn't have to get the ports precisely lined up in the first place: The cable's 50m long. This does have the potential disadvantage of the docked craft drifting around on the end of a 50m cable, but if you retract it all the way, it'll go into 'locked' mode which only allows some flopping about (which is curable with docking or quantum struts). I can see retracting the cable all the way being a bit tricky, as KAS has a habit of yanking on things rather hard when the cable initially runs out, which could very well send the docked craft flying at the station faster than the cable can actually retract. You CAN avoid this if you're careful and patient, though. (I may not have KAS Docked in orbit before, but I *have* used a grappling hook to grab a piece of debris before. That was...educational.) The main disadvantage, however, is that you need an EVA Kerbal to plug the connector into the port in the first place, so it doesn't work on completely unmanned things. You could use a grappling hook unmanned, but it can't dock craft, just connect them.

Squad are in the business of making a GAME, not in the business of reprogramming an engine. They're not a major development studio with millions of dollars and thousands of employees to throw at such a task. They're a small, indie development studio, many of whom were formerly modders that did exceptionally good quality work. They'd have to all but stop development on the game for a period of time to do it, and that's assuming they even have anyone with the proper type of programming knowledge in the first place. And if they do, it's probably only a few, and it would sharply limit what the rest of them were able to do with those few completely tied up redesigning the engine. Given their circumstances it's not really possible for them to devote a lot of resources to something of that magnitude with so little of a return. As for expecting you to do it, you basically said all along that you could, did you not? We're challenging you to put your money where your mouth is. The fact that it would enormously benefit everyone involved (including you, since Unity plugins generally have to be Paid For) is a complicating factor. If it's as easy as you say, why are you continuing to troll up the forums rather than just doing it and selling the results?

Have you tried Dock Align Indicator? I haven't had a chance to yet, but I gather it's pretty good. (I'm held up by the rover problems.)

...Did not know that. Interesting. I'm honestly not surprised, though. But everything I'd heard was the Unity was strictly limiting it to one core. Oh well, the more you know I guess

Well there IS a multithreading plugin for Unity now, but from looking at it, it didn't really sound like it'd be able to do the Physics, and without the physics being multithreaded, well, it wouldn't do much for us.

The problem is that it's not an 'Optimization Problem' (they have, in fact, done some optimization already), it's a 'the Unity engine does not support that feature' problem. You can't 'optimize' something you can't DO in the first place. The only way multithreaded physics in KSP will ever happen is if a multithreaded physics system is made available for Unity. Unity themselves have no particular incentive to do it themselves, because honestly, how many of their customers need it? This means that most likely, in order for this to happen a third party needs to make an alternate physics system available as a unity add-on. Note that third party means 'Not Unity' and 'Not Squad'. In other words, unless you're going to go port a physics engine that isn't ancient crap to Unity, there's nothing to discuss here.

There's a reason I said 'by Default', not everyone realizes this.

DO Keep in mind they respawn after a bit by default.

On the subject of Apollo Hoaxes: The Mouseover Text: "Ok, so Spirit and Opportunity are pretty awesome. And Kepler. And New Horizons, Cassini, Curiosity, TiME, and Project M. But c'mon, if the Earth were a basketball, in 40 years no human's been more than half an inch from the surface."

Problem is, Squad isn't 'Coding the Engine' and doesn't have the capability to do so. As such they're limited to the capabilities available in the Engine. Multithreading in any capacity is not one of them. There IS a Unity plugin now to do multithreading for some things, but my understanding is that it wouldn't work for the physics, which means it wouldn't help us much. If you want to see this happen, port a better physics engine (PhysX 3 or Bullet, for example) as a Unity plugin. Until someone does that there's basically zero chance of it happening (because Unity has no particular reason to spend a lot of time on Multithreading).

Yep. I'm pretty sure the suspension is actually the cause, and is exerting actual force on the rover to try to lift it off the ground. But seriously: Don't just post about it here, go on the bugtracker, and post it there by hitting the 'Update' button. This is the most recent (and best) bugtracker item on the subject: http://bugs.kerbalspaceprogram.com/issues/1141