Tiron

...why did it make a new post instead of editing the previous one... *confused* And more importantly, where'd the delete button go!

Actually, originally I just moved the rover controls over to IJKL. My latest attempts moved them back and used docking controls so that I could experiment with active ASAS use. Which helped some on flat terrain but at one point seemed to actually lift the rover off the side of a hill, causing it to go tumbling down the hill and break. There's lots of things that help rover stability in general, and this isn't about any of those issues: This is about terrain segments that cause your suspension to lift your rover partially off the ground, removing almost all traction and control ability, and have a severe tendency to send you rolling down a hill if you're on one when it happens. Because right now, even with good design, lots of testing, and every other assistance measure, this bug still ends up flipping you over if you drive in hilly terrain (and massively slows you down if you don't). Actually, what happens is that Unity's wheel suspension system responds to invisible deviations in the terrain mesh: it thinks the terrain is in a different spot than it looks like it is, and tries to move according to where it thinks the terrain should be, instead of where the wheel is actually sitting. This causes the suspension to either harmlessly push the rover down or lift the rover up. The latter causes problems because it seems to actually be able to exert force on the rover, and tries to pull it right off the ground. The problem is that it partially succeeds, resulting in instability and lost traction. Even TT's Multiwheels, which work far better than the stock wheels in many cases, have this problem.

Exactly. I just don't think Squad realizes the scope of it, so how do we fix that? Bring it to their attention.

1.) I already said it was limited by unity in my first response to the OP. 2.) I'm not complaining about it, you should keep track of who you're responding to and read the entire thread. The OP hasn't deigned to respond so far. I doubt it, especially since it's not so much 'ocean generation' as 'ocean rendering'. One thing to keep in mind here is that there IS a surface beneath the ocean, which isn't just flat and featureless, which complicates the Rendering. Another thing to keep in mind...Kerbin is bigger than most of the other bodies, so there's a larger surface area visible at one time My main point though, was that if you somehow (don't ask me how, I don't know) got the Physics running on a separate core, all the resources the physics were using before would be available for that. Assuming that's not just a 'Overloading the GPU because it isn't optimized' Issue, which it well may be.

Well, it actually only supports one core for...er, well everything, actually. The physics is the part that's the biggest problem, though, because it's far more intensive than everything else. Hell, just being able to run the physics on a separate core from everything else would help, probably even with what you mentioned.

Depends. I keep two groups of staff ready to go: Pilots, and Cannon Fodd...er... "Experimental Test Pilots", yeah, there we go.

Er, the Kraken didn't get Minmus... we did...with the SRBs... http://www.kerbalcomics.com/2012/07/30/episode-12-fighting-spirit/

KSP is only going to use multiple cores if Unity somehow gains the ability to do so. Right now it's using an ancient version of PhysX that isn't set up to do it (and has other issues that cause all sorts of other problems too, like unstable orbital parameters and the Space Kraken.) There's also no alternatives, as the only add-on physics package that was being worked on for Unity has seemingly been abandoned by the one guy that was working on it.

Okay. First, Alpha means 1.) Half Finished, 2.) Not Released. Think of it as getting early access in exchange for buying a severely discounted pre-order. Tons of games do it, just not this early in the process generally, but most games don't do it to fund the development. Second, there simply ISN'T a better base to build from without starting over at this point. The game relies almost entirely on Unity's ancient, single-threaded PhysX. Last I heard, the One-man project to make a Bullet Engine plugin for Unity seems to be abandoned, as well as unfinished and unreleased, and there's literally no other options. If you, as you try to claim, know ways to work around it, tell us! How do you get Unity to run multithreaded Rigidbody physics simulations. This is the one thing that holds KSP's performance back more than anything else, so if you really know a way nobody else has thought of in all this time to do that, do us a favor and enlighten us.

...We got Minmus.

Did you know quotes don't count towards 10char?

All polls are flawed. It's impossible to think of every possible response. Some are more flawed than others, sometimes deliberately, as the options or questions are asked leadingly. I annoyed the heck out of one 'survey' taker during the 2008 election when I stuck by my answer even after he A.) Asked the question in a ridiculously leading way. B.) Asked AGAIN after trying to emphasize his point in an equally biased, leading way. I'm honestly not sure it actually WAS a survey and not just trying to get a particular message out about something while disguising it as a survey.

Alright, after two versions with this problem without so much of a peep, well, I'm tired of this being treated as a minor issue and pushed aside. The terrain/suspension problem on rover wheels makes all rover use a crapshoot at best and futile at worst, as it *will* go tumbling down a hill and break sooner or later as a result. Squad don't seem to grasp how big of a problem it is, since the most recent bugtracker report (with the best reproducibility I've seen on one yet, complete with a save file) has been downgraded to 'Low'. It's not 'Low', it's a major issue that's seriously affecting an entire core game function. So do all of us a favor: If you're ever experienced the problem where the suspension on your rover jacks up, resulting in the rover losing traction and bobbling about and/or flipping over, please add a comment on your experiences in this regard to this bugtracker report: http://bugs.kerbalspaceprogram.com/issues/1141 We need to show them that this is a major, widespread problem that causes serious gameplay issues, and not just some minor niche thing that a couple of people are experiencing occasionally.

Surprised this hasn't come up before, but the way I recall it, the option to undo a Steam transfer in case of problems was specifically for problems with the TRANSFER. They gave an example (which actually happened to some people as I recall) where the transfer basically only partially went off, leaving you in a state where you couldn't get KSP from either the store or from Steam, but also couldn't redo the transfer either.

Well a simple .cfg file edit didn't work. I moved the base noarch's model into the TTcarwheel_ folder renamed as model1.mu, and changed the mesh= parameter in that PART{} entry to match. It loaded the fifth part alright, but it ignored the mesh= setting (or maybe I did it wrong, I really don't have a clue, I'm just guessing at stuff) and loaded it with the 'arch' model anyway. But at the very least it looks like you can now do variants on a part as just extra entries in the .cfg file if they share the same model[Edit: And texture, since it's specified in the model as I recall?]. Makes sense. Why else would you start requiring that PART{} wrapper except so that you can have more than one of them in the same file? Edit: Well I don't know if it helps RAM usage any, but I do right now have all four of the arched littlecar wheels loading from one set of assets, so the download'd be smaller, at least. Edit2: It occurs to me that this might cause problems with some of the landing gear that have different textures for the different variants, that make them say what variant it is right on the casing.

Yeah, I don't disagree. It's annoying having to flip it on and off every time I launch it. You missed my edit though, after I tried putting all four of the 'TTcarwheel_' variants into the same .cfg file. Short Version: it worked. All four variants loaded as separate, working parts from one model, one texture, and one .cfg file (with the four PART{} definitions inside it) in just one folder. Edit: Now I'm wondering if it might be possible to get the noarch variants in there too...they use the same texture so if there's a way to put two models in and have it load the second one with the first texture... now I'm really going out on a limb, lol.

If you use the connector -> connector port 'docked mode' connection, yes. Which means you need an EVA'd Kerbal in order to make the connection. Hooks can connect without going on an EVA, but can only use 'undocked mode'. Swapping hooks or making 'docked mode' connections requires a Kerbonaut. 'Docked Mode' works the same as if you used a pair of docking ports. Just there's a 50 meter cable in there, so you've got a LOT more wiggle room on positioning. As for Kerbals pulling stuff, I discovered that if they're carrying a part on the end of the cable while pulling, the extra weight of the part increases their pulling power somehow. With the 1-ton anchor on their back, a single kerbal was able to flip my 2 ton rover back upright by pulling on the cable, or even drag it around.

In your case, I *think* there's a way now to have multiple parts using the same resources, so all those different wheels you've got with the same model/textures but some with or without steering, power, or both, could just use one set of models, textures, and resources. No idea how to do it though, if I had to guess I'd say combine the part.cfg files with each one in its own PART{} wrapper. Granted, it's also possible to turn steering/power on and off via a right click config option like the stock wheels, but that might require modifying the plugin. Now I'm back I might try that 'multiple part CFG thing' just to see if it works. Edit: Alright, so I added the PART{} wrappers to the Littlecar_wheel U and S, then copied all four variants' respective part.cfg files into the U's cfg file, and removed the MS, M, and S folders entirely (to my desktop, actually.) This was the result: Notice how the path on all four of them shows '../Parts/TTCarwheel_/...' It totally worked. And when I took my rover fitted with MSes and Ms out on the runway, it worked perfectly. So that's one way. There might be deeper ones I suppose, I dunno.

IRL, there's two 'versions' of Isp, depending on how the quantity of fuel is specified: If it's given in Mass, Isp is given as a Velocity; if it's given in Weight, Isp comes out as a Time. KSP uses the latter format, as do most real world rockets because it eliminates any possibility of unit confusion. But yeah, posters above got it right: The Isp rating of an engine is not affected by any other engines attached. Imagine two identical car engines, attached to the same fuel tank. Turning on the second engine while the first was already running doesn't affect the fuel burn rate or power of the first engine. It just empties the fuel tank faster because now you've got two engines burning it instead of one. But you're also now producing power twice as fast, so it comes out to the same efficiency. The Delta-V of the rocket however *will* be reduced by the second engine. Delta-V stands for 'Change in Velocity', the greek letter delta (which looks rather like a triangle, but we don't have that on our keyboards so we just type it out) stands for 'Change', and 'V' is short for 'Velocity'. Delta-V is one of the most important things on a rocket. It indicates how much it's able to change its speed. Changes in speed are required for every single type of maneuver (even just changing directions is classed as an acceleration), so Delta-V measures how much movement you're able to accomplish. Extra Mass decreases Delta-V because of the extra inertia that has to be overcome. Practically, in some circumstances the Delta-V reduction doesn't matter: During a launch, if you don't have enough thrust, all the Delta-V in the world won't save you from falling back into the body you're launching from. Thrust will. More thrust can also actually IMPROVE efficiency during a launch by reducing drag and gravity losses, potentially by more than the Delta-V cost of adding engines (or using less efficient ones with higher thrust and/or lower weight).

I actually did that with the TR-2Ls, and it didn't help a bit. Their inability to skid at all just makes them generate way too much force, it seems. And it doesn't affect the suspension issue at all. Now if your problem were the joint between the rover and the wheel flexing, it might help. Might, there's some kind of problem when placing rover wheels with SPH symmetry that causes the second one not to attach properly...

For the parts themselves I don't think it's too hard, I could be wrong though. It's the plugin that might need some work doing. All I know for sure is that within a very short time of 0.20 coming out, a random third party hacked a fix for Kethane 0.4.3 together to get it working (it was COMPLETELY broken by 0.20). The fixed version had the PARTS in the new folder structure but the plugin in the old folder structure (Mostly, I think it had to have the plugindata inside the plugins folder like on the new structure, but I distinctly remember you still had to put it in the root plugins folder or it wouldn't work). I'm pretty sure a modification to the plugin was involved, but I gather it was a quick, minor one. And it didn't work at ALL, as opposed to your multiwheels, which do. Let me just check something right quicky... Edit: Well, I moved all the multiwheels parts to GameData/TohouTorpedo and left the plugin where it was. Predictably, none of the parts loaded, but I'm an old hand at fixing THAT particular problem... After a minor edit to the part.cfg files of the three parts my experimental Multiwheels rover uses, it worked fine. The same modification I made to get the old spaceshim part working to use as a fuel crossflow blocker. It consists of modifying the existing part.cfg files in the following manner: Yep. Just add six characters on either side of what's there. You could do it with a batch file. I've only done it with the three parts my rover used so far, but it seemed to function perfectly, so that might be all you need to do to get the PARTS into the new filesystem, while leaving the plugin where it is. On the other hand, moving the plugin might be more complicated, because it has to move from '<root>/Plugins' to '<root>/Gamedata/<TohouTorpedo>/Plugins' . If it has any non-relative file calls it in, it won't work if it's moved. If it doesn't, well...it might. Hang on, I'll try that too just to see... Edit2: Okay, with the parts moved to Gamedata/TohouTorpedo/Parts, multiwheels6.dll moved to Gamedata/TohouTorpedo/Plugins, and config.xml moved with it (it was already in plugindata in plugins, interestingly), the three parts I modified in the prior test *still worked*. So preliminary indications suggest that multiwheels at least might just need the .cfgs updated to be moved into the new file structure. The fact that it didn't seem to throw the plugin for a loop speaks to good coding practices on your part TT, so good job!

It's an interaction between the terrain and something with Unity's crappy wheel setup. I heard something about imprecision in the terrain mesh: basically, the suspension reacts as if the terrain were slightly higher or lower than what you see (and are driving on), so it pulls up/pushes down trying to conform to where it thinks the terrain is. It's only a problem when it pulls up, because it actually starts trying to pull the rover off the ground, and partially succeeds. The REAL problem there is that if you're on a hill when it happens, there's an extremely high chance you'll be rolling down said hill seconds later if you're at any kind of speed. Interestingly, before stock wheel were added I used to cruise around with the old Bigtrak rover, and it was actually FASTER on the Mun than on Kerbin. Over twice as fast, in fact. I got it up over 90 m/s one time. But then again, it was completely immune to damage, so when it'd end up in a tumble after catching some air (and at that speed on the mun it catches air off every tiny rise), nothing came of it other than stuff on the outside of it getting broken. I dropped one from LMO one time by accident, and it survived just fine. But then, I don't think the Bigtrak HAD a suspension, and I also think that's why it never had any of the problems the current rover wheels do. Even TT's Modular Multiwheels have the same suspension problems as the stock wheels, so it's clearly a Unity problem. I've tried disabling the suspensions on the stock wheels to test if I'm right, but only succeeded in making the wheels not work at all, so I'm kinda stuck. Edit: Some interesting, semi-random facts I discovered while trying to build a safe-esque manned rover in 0.20: TR-2Ls have a tremendous amount of friction, which is a large part of why they work so well, with basically zero ability to slip. This includes even the non-tread parts of the wheel, like the sides. One of the results of this is that if you catch air and then come down in a direction that doesn't allow them to rotate, they basically stop dead on the spot, which causes an ENORMOUS G-Force spike. At about 30-35 m/s ish, this spike gets strong enough to rip the wheel off the rover entirely, and possibly knock the Kerbals out of their command seats just from the jolt. At around 50 m/s, the jolt from even regular structural members hitting the ground gets strong enough to start breaking off radially attached parts. Things like RTGs, Probe cores, and command seats (the wheels and Kerbals are probably long gone at this point, but only a direct impact will take the wheels off even at this speed.) From further testing in 0.21, when the new terrain made it worse: Rovemax 1s basically can't climb hills. And are still the first thing to break off if you go tumbling down one.

Well as you can see, the 'pick up stuff and move it' aspect most people do with KAS, one of the most awesomest mods of all. Thing you run into there is counterbalancing it: If you try to pick up something heavy and you're not counterbalanced, at best you'll tip your rover over, at worst you might lift the rover instead of whatever it is you're trying to lift. The OTHER trick being is that KAS itself might obviate the need to move whatever it is you're trying to move anyway, if a Kethane tanker is involved: KAS allows you to dock two craft via a 50 meter cable, attached to a connector port on the target craft by a Kerbal on EVA. The winch, connector, and port weigh a bit more total than stock docking (at least the Jrs, and maybe the mediums), but it's all concentrated on the 'winch' side (the port weighs very little). The big helpful thing for Kethane setups is that because the docking connection is made by a Kerbal taking the end of the cable to the connector port, you don't have to somehow get the two docking ports aligned to transfer the Kethane/Fuel, you just have to get within 50 meters. There's even a detachable radial connector port, which can be taken off one craft and placed onto another, allowing you to KAS dock with a craft that didn't have a connector port in the first place. There's also a pair of 'hooks': Grappling hook (attaches to anything it hits hard enough, or can be manually attached to the ground by a Kerbal), and Electromagnet (attaches only to parts, uses lots of electricity), but neither of these allows docking, just grabbing. And there's a big heavy anchor for airships.

Actually, that's EXACTLY how the Soyuz lands: Parachute descent, but fires some tiny solid rockets just before it touches down to slow it down a bit more. This is due to the fact it was designed to touch down on land, as opposed the old American capsule systems which were designed to touch down in the ocean. And three parachutes doesn't necessarily mean triple redundancy: The old Apollo capsules used three but actually required two of them for a safe landing. The chances that two would fail on the same flight were considered pretty low, though (the same logic that skydivers rely on in only carrying a single reserve, which is generally lighter, more tightly packed, and doesn't slow them down as much as their main chute.) This worked out pretty well for NASA: the only Apollo flight I know of that had a parachute failure at all was 15: the crew reported all three inflated initially, and first noticed one of them had collapsed after the RCS fuel dump. It was later found to be missing shroud lines, cause unknown. (But speculated to be the RCS fuel dump) Edit: I suppose the advantage to doing it that way (3 chutes, 2 required, 1 pseudoreserve) is that you end up only having to carry 1.5 times as much parachute as you need, as opposed to 2 times if you use two that are both big enough to work with just one of them open.

Yeah, it's called 'Fly by Wire' in the Aircraft Industry. Originally invented for Jet Fighters because it allowed them to use designs that are actually aerodynamically unstable, and thus far more maneuverable. With Negative stability, it's already trying to turn in any direction it can get the tiniest start in, and the only reason it doesn't is the computer making constant adjustments to keep it flying straight. So when you actually command a maneuver of some kind, it pretty much literally LEAPS into it. As opposed to a plane with Positive Stability(which you have to drag kicking and screaming into the maneuver) or Neutral Stability (which just sits there unresisting as you move it around). But on ANY plane with fly-by-wire, you're not actually in control of anything. Your inputs just tell the computer what you want it to do, and it figures out how to accomplish that and carries it out (within limits, in most designs). The F-16 for example. The original version of the F-16's Side-Stick didn't actually move, at all. (I guess it uses strain sensors or something?) The pilots had tons of problems with that, so it was modified to have an EXTREMELY small amount of play in it. I also gather from things I've read that the computers actually limit the maneuverability on it, and that there's some kind of a toggle that can set the limit to either a higher or lower setting as desired. I forget the exact details and I'm too tired to look for them right now. Sorry