Tiron

In a sense, you're right. It's pulling the data from the game, yes. But then IRL scanning satellites pull their data from the Earth. The difference being the data was oh so very analog and not already digital. ISA doesn't come with a pregenerated map texture that it exposes as you pass over the surface, it uses a series of beams (how many is selectable in the options) that cover a swath 16 degrees wide, centered on your position, that pull the height data for the spot they hit. If they come close enough to an object, it gets saved into the anomaly database. The point is, there's no way to simply pull a completed map and anomaly database from somewhere. To get it you HAVE to put a ship with an ISA Mapsat dish into orbit, and have it pass over the planet in such a way that its 18 degree swath ends up, at some point, touching every point on the planet. Using a higher orbit does so faster, but with a lower resolution (though you can now mitigate or eliminate that by using more scanning beams...at the expense of rapidly increasing CPU load as you add more). I tend to do ISA and Kethane mapping simultaneously, but the Kethane scanner doesn't HAVE a swath width. It only scans the point directly beneath you. It's gotten easier to use with the recent updates, however, which changed the scanning to be based on a geodetic hex grid (and some pentagons, of course), so you don't have to somehow hit EVERY point on the planet, but the grid's still pretty fine. It still requires you to take a lower orbit with a finer grid in order to hit everything. The lower orbit makes it take longer. A LOT longer. About 3-4 times longer, generally. It also seems to me that by your definition it'd be impossible to actually scan a planet, because it's all already data in the game's databases, if not the mod's. But let me ask, what's the practical difference between a beam that pulls data directly from the game's heightmap, and measuring the beam's return time to determine the distance? Sure it's more accurate. And probably faster. And gets you the height directly rather than a database of relative heights. But the practical effect is the same. You're basically pointing a radar dish(With a massive swath) at the planet and making a map based on the result. Unfortunately, you can't at present get the data from the mapper via an uplink, you have to be sitting in the ship with the dish in order to collect the data...which is most of what's so annoying about it. You have to leave the game running with your mapping probe focused for hours of realtime. I'd just rather minimize how much of that I have redo, because it's really...not that fun. But it makes other things easier and more fun sooo...

flex in the structure, possibly. Either between the arms or...well, in my experience using symmetry with wheels doesn't work very well...because the 2nd wheel doesn't really lock on to the part. It kinda vaguely floats there, and will move around quite a bit relative to what it's locked on to...I've taken to placing wheels individually.

Designing planes to be able to recover from a flat spin... I'm TERRIBLE at judging when I really shouldn't push it just a bit higher.

I made a rocket once that used giders for its primary structure, with tanks hanging off the sides and the engines on the girders at the bottom. Tanks would get kicked off the sides when they were expended, in asparagus pairs, with the engines not getting dropped at all. It was part of an attempt to make a supermassive fuel-to-orbit hauler, and that was only supposed to be the core, with the tanks in question not getting expended, at least not mostly. The first test with just that core worked, arriving on orbit with almost no fuel left. All attempts to add additional tankage and SRBs in order to increase the mass to orbit resulted in horrible crashing, mostly caused by wobble in the girder-to-girder joints. The design was eventually abandoned because stabilizing it was requiring so many struts it was defeating the original purpose of getting the part count down versus a more traditional design. Part of the core concept could work very well though: Keep the engines, and just drop tanks. It worked absurdly well, with the TWR constantly increasing as it climbed, and never a loss of thrust. As for why asparagus isn't used in real life... Rather than angular momentum issues (Consider that the flow rate drops off at each engine, so most of the fuel flow is on the outside of the craft anyway, with much less reaching the inner portions), I suspect it's far more simple: Complexity, Reliability, and Expense. Even with our click+click fuel pipes an asparagus setup is complicated and delicate, easy to screw up by doing one thing just a bit wrong. Imagine how much more so it would be in real life, where there isn't a simple GUI to build it with, and drag and drop off the shelf parts that snap together. Not to mention fuel pipes with unlimited flow capacity! Imagine how hard it would be to build a fuel plumbing system with the capacity and capability to asparagus stage. How many pumps you'd need, how fast those pumps would have to push fuel on the first few stages. How massive the pipes on the first stage would have to be to supply 2 and a half engines, let alone more as we sometimes build. Consider how you'd cope with the fact that the burn rates would never be even, since individual rocket engines vary in thrust unpredictably. When you think of it in terms of what it'd take to build it becomes pretty apparent that it'd be enormously complicated, and an incredible feat of engineering. And finicky as hell, because if even one part of the system failed to work properly, you're not going to space today. It'd be difficult, unreliable, and expensive. So much so that the gains might not be worth it. At least not without a ton of development. Rather like the cluster engines the Russians are so fond of.

There's some wiggle room, but the version of PhysX built into Unity is very old and very limited. It is theoretically possible to use something different, but right now there's no good, relatively easy way to do so. Someone was allegedly working on porting the Bullet engine as a Unity plugin, but it's stalled or something, because he hasn't posted anything on the subject since December. They've already put in a few things to work around some of those limitations (The physics instability used to make ships wobble and even tear them apart), but they're pretty limited to what they can do. The main problem is simply how massive the numbers it's being forced to work with are, even with the size compression. It wasn't built to handle numbers anywhere near that large, and rounding errors creep in as a result, which is where the instability comes from. One of the main places, anyway. At some point it's going to need to be fixed if the game's going to continue to grow, but I gather it's been pushed aside, either as an optimization thing to do later or simply being ignored because they don't think there's really anything they can do about it.

I'm honestly not sure if he's joking or just doesn't understand how much energy we're talking about. You'd at least think he'd understand the whole 'extra weight = LOT of extra fuel and complexity' thing...

Which is why I polished off Minmus and am waiting for that dev blog before I do any more scanning. If they're going to be futzing with terrain I'd like to minimize the damage.

Yeah. The problem here is the way multi-docking works: the first port to lock on forms a full connection capable of crossfeeding fuel. But the stucture's always built as a tree, logically, so the 2nd and 3rd ports can't also fully connect. They merely form physical connections, as if there were a strut connecting them. Simply put, that design is never going to work as it's currently built, because you can't have fuel crossflow through all three outer arms at once. You're either going to have manually shift fuel around or redesign it so that all the fuel flow goes goes through a single, defined port between sections. Sucks but it's a fundamental limitation of the game design atm. Edit: Or rebuild it so that the three outer arms on each section are three seperate pieces. The easiest way to do this would be to connect them to the center section via a docking port pair. After you make the initial dock, you could then go around and undock the ports connecting two of the outer arms to the center (ONE can stay connected, because it functions as the parent for the central section), then reload the scene. Disconnecting the ports connecting them to the center will allow their top port to change into 'full dock' mode, and reloading the scene will cause the ports connecting them to the center to reconnect in 'physical connection' mode and hold the thing together. Do it right and nothing moves physically, but logically the tree changes so that each outer arm is a separate 'branch', with fully connected ports all the way down.

Given that I already know my design works, and works well, and I've got my joystick set up in KSP...it wouldn't be much of a challenge really. I already KNOW I can do it, I just haven't done it fully manually. It'd be little more than a formality at this point, or I might try it. As for plugins, most of the ones I use are there for utility purposes and wouldn't be anything except extra weight on such a flight anyway: KAS is a winch-and-cable attachment system, although I grant the possibility is there to use it to refuel a plane on the ground...I only put it on orbital designs though, because a connector port's a lot lighter than a docking port, and smaller too (The winch you need on the other end to actually CONNECT to that port more than makes up for the weight, especially if you include hooks). Similarly with a kethane scanner, although if you added a drill, a refinery, and some serious power generation you could again potentially land and refuel. ISA Mapsat On the other hand is just a mapping plugin, and almost completely harmless. I frequently include an ISA GPS Unit on suborbital designs, so I can pull up its smaller map to see where the heck I'm at without having to go out to the full map. Unless you're counting finding KSC while flying manually without losing control as part of the challenge.

Well you could always just hax the persistence file to make the pod empty, but what fun is that? You don't need ladders to EVA them out either. EVA them out, let go of the command pod, and hit escape-> End flight while in freefall. It's not cheating because they were never there >.> <.<

For a large, multi-parted object I suggest doing it from something else flying nearby, and DON'T hit what you're focused on. hitting something big with lots of parts tends to send bits flying off, and if you hit the bit you're focused on you get sent to another part in an order that's hard to predict.

Well, I've got a free-flying voyager probe with only one part, so that'd be boring. Its booster is somewhat behind it in the middle of a bi-elliptical transfer to the sun, that might be somewhat interesting. My mapping probe is still at minmus, with enough fuel to go several more places. There's a piece of debris from the voyager probe flying around between kerbin and about duna's orbit somewhere, but it's empty so no good explosions. And the rover on the surface would stand a good chance of surviving being hit. I might try that...

Because it used to be really easy to go to the Mun with just RCS if you did it right. As for what I did today, I mapped minmus...and then stopped when Harv said 0.21 breaks compatibility.

ISA Mapsat doesn't work that way. It actually DOES scan the surface, using an adjustable number of scanlines. It comes with no pregenerated map textures and no database of locations (it has a database of maximum and minimum altitudes for each planet, however). That's most of why it's so neat: Saving the raw scan data allows you to generate maps of more or less an arbitrary size. I used to do that to check the fine resolution of my scans, generating huge maps to pore over while zoomed in. It may have worked the way you say at first, but not any longer. Edit: You know, I forgot about one of the features he added in The dev version of mapsat 4: There's now a button to regenerate the altitude database, which he claims is to allow you to scan new planets without him having to update the plugin manually to do it. Edit2: Okay, it's not a button, it's a checkbox (a round one that lights up but...) It checks for missing planets automatically if enabled, but apparently it's a fairly time consuming operation to calculate the altitudes and add them to the database. That's my guess too, but you are now officially my favorite person for the day.

Everything in KSP is compressed. Kerbin has Earth level gravity and atmosphere but only about 1/10th of our size. Earth's atmosphere extends much higher than Kerbin's, and never really 'ends', it just tapers off. The atmospheric density at a given altitude varies as well, mostly from variations in solar activity. Just such a change is part of why Skylab came down before we got the shuttles operational: Higher than expected solar activity extended the atmosphere and brought it down much faster than expected. The shuttle getting delayed didn't help either. In KSP we don't consider a craft 'in orbit' until it's out of the atmosphere, but most real world orbital operations are conducted in the very thin atmospheric edge. Part of this is because you can't go on rails while in atmo. Real world orbits decay because there's still drag at those altitudes. In KSP there's not, so without interaction an orbit will NEVER decay. That said, the real insidious part of Kessler Syndrome isn't possible in KSP at the moment. When a part is destroyed, it produces no debris. The only debris that can be produced in a collision then is surviving parts. Solar panels DO produce bits of debris when destroyed, but they're not tracked. They despawn very quickly and never get a chance to be a problem. Engine fairings follow the same behavior.

Maybe in the software development industry at large, but when it comes to game engines...well. There's a shining example of what happens when you realize your engine is outdated, so you switch engines. It's called Duke Nukem Forever. Development was first announced in 1997. There were erratic releases of promotional materials, and various release dates were given up until 2001 when they finally declared 'when it's done'. Nothing further was heard until 2007, when a new teaser trailer emerged. In 2009 3D realms, the creator of the character, basically went bankrupt and ceased development, purportedly with the game 'nearly finished'. They were sued by their publisher for failure to deliver, details of what happened are obscure, but 2K announced that Gearbox was finishing it sometime later, and it was released in 2011. They originally licensed the Quake II engine to make the game in (for a reportedly exorbitant fee), but 14 months later decided to switch the brand-new Unreal engine. A few years later they switched to Unreal 2. The game was eventually released using a heavily modified Unreal 2.5(Apparently almost totally rewritten from scratch), and having gone through at least two physics engines as well.

That's how Kethane works, sort of, because kethane is showing the deposit locations. ISA actually sends out beams to the surface that determine the distance, creating high-quality, very accurate maps, even of the ocean floor for those planets which have an ocean. When one of those beams encounters an 'anomaly', it gets saved in a database and can be used as an overlay. There's also an option to enable saving the raw collected data in a csv file, which you can then use with an included tool to generate maps of pretty much any size you like. Even change the colors used. The upside is you get accurate maps without an update if the terrain gets changed. The downside is there's no way to hack in a completed map, other than downloading one off someone else.

If it could, I would be exceptionally happy. Unfortunately it only works while the craft is focused. Innsewerants was talking about having an idea to be able to link multiple mapsat units in the same SOI so you can map things faster... some time in the far distant future. Right now you have to leave it sitting, orbiting the planet, for hours, and can't do anything else in the meantime. Yes. If the maps are still accurate. I've heard mention of 'Art Passes' on some of the planets, which will almost certainly change the topography and possibly the anomaly locations and/or number, requiring remapping.

Agreedo. I've got a plane that I *have* already circumnavigated in (In less than 50 minutes despite overshooting KSP and having to come back), but I let mechjeb handle most of the flight. Manually nannying a plane that I already know can make it and land (and still have quite a bit of fuel left) for 47+ minutes isn't my idea of a good time. Especially not to fulfill some arbitrary restrictions for the sake of a glorified sticker. That aside, I wouldn't uninstall KAS, ISA Mapsat, or Kethane for this either. None of them affects the difficulty of the challenge. For that matter, Mechjeb2 doesn't particularly either. Its altitude hold mode on the spaceplane guidance is terrible, porpoising you up and down, and the flameout protection isn't particularly any better, only able to handle VERY slow climbs without losing an engine. The end result is you end up setting it lower than you actually could fly so that when it overshoots upwards, it doesn't go high enough that it flames out. On a two-engine design like mine it's particularly problematic, as even a momentary flameout spins you. When I circumnavigated it on the initial test flight, I actually went too far because I spun it multiple times pushing the altitude, and ended up a fair ways north of KSP as a result. So yeah. Some seriously bad restrictions on this. If someone else doesn't mind them so much, I posted a fully stock version of the craft in question (which merely removed the Mechjeb, ISA, and Sunbeams from the original) months ago. http://kerbalspaceprogram.com/ravenspear-mk3-d-manta-stock/

I think it automatically load balances. You CAN assign core affinities to various processes, but it's a pain in the butt and generally not recommended.

Doesn't work, because they're actually creating maps as they pass over the surface. ISA Mapsat creates topographic maps and a database of anomaly locations. Kethane creates a map of where the Kethane deposits are. Simply moving the probe back to where it was doesn't recreate the maps. Kethane, the more annoying of the two, isn't based on the surface and there's no reason it couldn't be saved even through a save compatibility break...other than majiir breaking it himself in the meantime. But if they change the anomalies (Adding/Removing some, changing locations other than vertically) or the surface, my ISA maps go out the window and have to be recreated. The fastest Kerbin mapping orbits take about 15 hours game time. For the Mun, about 19.25. Minmus, about 22.5. And you can only pull about 10x time acceleration, or you pass over the surface so quickly you end up with very bad data. So it ends up taking hours and hours, each. I've done this probably close to half a dozen times now.

Blaming or not Blaming Unity doesn't change the simple fact that it's the cause of many of the limitations on the game, and that in order to change it they would essentially have to drop Kerbal Space Program and start 'Kopiers' Space Project' themselves. Changing game engines is NOT viable. Even changing Physics engines is probably pushing it. What you don't seem to understand is that there are certain things that can't feasibly be changed at this point, because it would take so long and cost so much that it would risk bringing down the project entirely. And sooner or later someone else WILL do it better. It's inevitable, no matter how good your original product is, it will eventually be exceeded. As for development, are you asleep? We've had plenty of major additions recently, and are by the sound of it about to get more.

Not sure. Craft might or might not still work, since 'still working' is semi-independent of if the .craft file loads. They might change something that makes it no longer able to function correctly without being reconfigured (IE: When they fixed the bug with fuel use while throttled down).

Wrong button...where's the delete post button