Tiron

Well, I tried the 120% wheels out on the Mun. That's funny. They slip and slide like crazy still, which actually comes out to an advantage at times. Get a bit sideways, and instead of catching and flipping you over, they still skid, even on 120%. at least with my rover design, which is pretty low and wide. I just happened to catch air when I hit screenshot. Meh. Went down a crater rim-wall, it was very smooth so I just went for it. That was the result. I end up steering with the reaction wheels instead of the actual wheels when I'm at speed, which seems to work okay. Only had one major crash and that was my own dumb fault: I went over a crater rim edge at 40+ m/s and caught serious air. It wasn't even that big of a crater. The impact knocked both Jeb and Bill out of their seats (and eventually out of the rollcages), but survived. Controllability is decent as is hillclimbing so far, despite the lower gravity.

Actually, I removed the containers from the plane because I suspected them, replaced the flag, and then flew the plane into orbit. I just didn't quicksave and quickload that time. I did forget one other common factor between the two attempts: both craft were on mod wheels with suspensions. The test craft that kept blowing up was on rollkage wheels, the plane is on TT Modular Multiwheels landing gear. Only the wheeled portion of the test craft was doing the 'teleport into the ground thing', and that was also the only time I saw it happen in-flight, and not just right at physics load. (I was trying to use it to pull on pipes to see what would happen.)

I should add: The common factors in both cases where I had this problem were Type A containers in racks and Physical KAS connections between parts of a docked craft: pipes during testing (forming the dock as well), and struts with the plane (attaching the rotating cargo-bay to the rest of the plane, as well as the rover in the bay to the bay itself. The rover is docked to the bay via a pair of CoT Jrs.) When I edited the plane off the runway it continued to the do the same thing, at the instant of physics load it would teleport down into the ground, then get violently kicked out. The last time I tried it, the front half of the plane survived, so I decided to roll with it. There were some interesting errors after everything came to rest. The Rover ended up beneath the bay, despite the bay still being closed and the docking washers still attached at either end (it had to clip through something to get there). The CoT Jrs were intact, and at first it seemed as if the rover were still attached to the bay. It came loose shortly after, despite not having been undocked. When I got poor bill out to the rover and tried to use it, it didn't work because its Okto2 probe core (the only battery storage it has, it's nuclear powered) was...broken somehow. No storage, no control functions, no right-click menu. One of the containers in the cargo bay survived and I was able to get a battery out of it, which got the rover working again. I just took the container out of the bay entirely, and laid it on the ground there. Didn't see the point in having it sitting in the bay uselessly. Then the cargo bay and the rest of the front half of the plane still attached to it started floating off into the air like there was no gravity (and no, I didn't hack it.) I tried switching craft to it and was not able to: I could switch to bill, the rover, and every other piece of debris, but not the floating front half of the plane. It should've still been well within range, because I didn't get a range indicator on it, and it didn't look too far away at all. When I loaded a new rover and plane in to try again, my flag at the Mk1 Pod Memorial fell over and exploded. Saving and reloading multiple times resulted in the same thing. It was kilometers away from the 'crash site' and couldn't've possibly been directly hit by anything.

Bit a bug I'm having here, that seems to be KAS Related. I was testing the new version on the runway, and occasionally part of my testing setup would suddenly teleport downwards. It'd instantly go through the runway onto the ground beneath it, only to then collide with the runway, destroying the central part and sending the rest flying. Now I tried to quicksave and quickload my plane on the runway because the 'resources' display wasn't working(The plane has some KAS Struts engaged). It's now doing the same thing: The instant physics load in, it teleports down into the runway, it gets kicked back upward, some stuff gets destroyed and the rest goes flying. Never seen anything like it. (Can't seem to get a screenshot of it embedded in the runway, they all end up being just a moment later after it's been shoved back out.)

Mu. The User below me has never built an SSTO.

64 bit would only help so much, if any: reports are that the 64 bit linux version still has the same memory limits for addons as the 32 bit version. Even if it raised it, it's only going to raise it to whatever your actual physical memory memory is, minus whatever else is getting used. In my case, that's all of about 2gb (for a total of 6 the game could use). Anything past your physical memory would have to go into virtual memory, and if you thought loading was slow NOW... The problem is, as you pointed out, textures. The way the game uses memory for textures is really piss-poor, and stuff I've seen in local testing suggests it's probably not even USING most of it except during scene loads. This includes Mapsat: My testing has indicated that the number 1 use of memory in Mapsat is, predictably, the map textures themselves, which are using about 600mb total, an amount that doesn't change with the mapped or unmapped status of the various planets. That last bit indicates that the memory usage involves uncompressed textures: if they were compressed it'd vary. It's actually TOO HIGH for the textures to be getting loaded just once uncompressed: In fact it's more than double the size that all 30 map textures would need if decompressed. It is, in fact, consistent with two compressed and two uncompressed copies of the maps being loaded into memory. This suggests that all the intermediate steps in loading the PNG into the vidram are being cached in main system memory. On my setup I've seen indications that the actual in-flight memory usage can be as low as 400-500mb, even with mapsat and multiple other mods running. This suggests it's a problem with the way the game is using memory for textures (which it shouldn't need main memory for once they've been loaded into VRAM), which is consistent with the high memory usage of every other mod with lots of textures(or very high quality ones). The fact that people get out of memory errors from it implies that possibly the these cached items are being flagged as actually being in active use instead of being marked as cache that can be overwritten. In short: It might be a problem with the game itself, not Mapsat. I don't know how to use the debug tools to find out, and so far everyone else seems more interested in blasting Mapsat for being a piece of crap and demanding something else that would most assuredly be better. Based on the evidence that I've got, there's no indication that anything else would be any better because there's every indication it's a generic problem related to the fact that Mapsat has very large textures. But nobody but me is bothering to gather and consider evidence of what's actually going on, it seems like, which is a shame because I literally don't know how to go in and examine it in detail, and thus can never be sure. There is hope though. From the Sept. 10 weekly: (Emphasis Mine.)I saw a very detailed bit of research on the forums that indicated the biggest thing holding up the scene transitions is texture processing. Textures are most DEFINITELY the single largest memory hog, and generally the texture memory usage is what limits how many mods people can install. He says he's working on scene transitions (the only place the memory usage is actually high according to my testing), and optimizations for large numbers of parts. I'm hopeful that in the process, the general memory usage problem will get addressed to some degree or another.

Yeah, I'll have to look at that later. Right now I'm more worried about developing a method to carry the bloody rover places. 18 m/s...is not right though. That last time it had no trouble steering up to over 30 m/s...no idea what that was all about lol.

It's not ENTIRELY graphical, because when it goes upwards it kills the traction too(But only after it hits the stops, like it's still pulling upwards). Seems like the suspension actually exerts force on the rover, pulling it upwards and ruining your ground contact. Multiwheels do it too. In theory if that's the case the version that compresses the suspension should be pushing you down into the ground when it happens. Which should increase your traction, if it was realistic. I haven't noticed any particular effect from it. Edit: Didn't want to reply to this till I tried it. It's quite good. Just going around the space center for now, they still slide all over the place, but it's much more controlled. Instead of just spinning out or whatever, it's more like a drift. Can't wait to see what it can do up a hill when I get it into the mountains in a bit. Edit2: Some other side effects: They're faster and accelerate harder, topping out around 39 m/s on the runway. They also lose most of their turning ability above 18 m/s or so. Granted the steering and torque curves are both adjustable via .cfg, so I may play around with those.

The Kerchlin Extremes, my rovers tend to be right around 2 tons (this version is just a tad bit less) and the wider wheelbase on the extremes versus the sports helps a bit. As for how much...I don't really know. I'd have to agree that 20% would be the ABSOLUTE maximum. I don't mind it slipping SOME, I mostly just want the hillclimbing ability a tad bit better. I'd say go conversativish and try 10%? Thanks for even bothering though. Not having an acceptable Rover Wheel has stopped most of my KSP gameplay since 0.20 came out. :| Edit: Unless you'd prefer to just go for it with a 20% increase. I'd be inclined to do 10%, try it, and if it's not enough bump it to 20%, but since I'm not the one editing it I can't hardly ask you to do that now can I, since you're already doing me a huge favor just to do it at all? 20% would probably be fine too, if you'd rather just do it once for sure and be done.

Haven't gotten it to the Mun yet, because my attempts to build a transport for my rover design have been stymied thus far. In fact, I've never had any non-downloaded Rover on any body but Kerbin, out of sheer frustration with the suspension bug. The bug is as follows: Certain terrain segments apparently aren't read correctly by the Unity wheel system. Specifically, they get read as being slightly lower or slightly higher than they actually are. This causes the suspension on the wheels to either slowly compress or slowly extend as you drive across the segment. Speed doesn't matter. It DOES stop and reset to neutral if you stop moving entirely, but ANY movement, no matter how slow, triggers the bug. It'd be an entirely visual problem if not for one thing: If, on one of the segments that causes the suspension to extend, it actually reaches full extension... it doesn't stop there. It continues to pull upward on the rover even with the suspension at the stops, in essence trying to pull it off the ground. It obviously can't completely do so, but it does PARTIALLY do so. This results in traction and steering authority going very nearly to zero, as well as inducing extreme lateral instability. Some people call it 'wobbly wheels'. The problem isn't the wheels, it's the suspension basically pulling the rover almost out of contact with the ground. It's caused nearly every single rover accident of significance I've had since I started trying to use built rovers instead of downloaded ones when the command seats got added in 0.20. The Rollkage wheels are for whatever reason resistant to it. The suspension still drifts towards the stops, but it does so quite slowly, and I've yet to see it actually hit the stops in either direction while doing so. The only time I've had the suspension-induced instability occur with Rollkage wheels was when I'd just gone over the crest of a hill and was going down the slope on the other side. Even then, it's rare. This bug is one of the major reasons for some of the weirder things people do to try to keep their rovers stable. Rockets pushing the rover onto the ground. Driving around in docking mode with the SAS. It's also pushed rover designs towards greater stability than is strictly necessary, because the lateral instability has a tendency to flip rovers if they're even remotely prone to it (which makes it massively worse on sloped terrain.) As it stands, with Rollkage wheels I was (barely) able to drive my rover design clear up to the top of the one of the tallest peaks in the range west of KSC without having a single suspension-induced crash. That's never happened with any other set of wheels I've ever tried. Just a tad bit more grip (not too much, we don't need another TR-2L, where the grip causes as many problems as it solves, and most of them are worse than the ones it solves), and they'll be, by FAR the best wheels made for the game. Heck, in a lot of ways, they already are. But it'd be all but indisputable then.

I second the question as to if it was something really blatant or if they merely forgot to remove something. For ages the mods parts I used were almost exclusively small things that stuck on the surface, and could be removed without much of an effect. I *did* put a stock version of one of my planes on spaceport, mostly just to prove a point in a thread about spin characteristics. (Specifically, that it was possible to design a plane that could recover from a spin without problems. I'd already done it, so I threw that up there as a demonstration.)

Eve has 1.7 times as much gravity as Kerbin and an atmosphere 5 times thicker than Kerbin's at their respective sea levels. The atmosphere also extends about 27km higher than Kerbin's. All this adds up to substantially increased drag and gravity losses, plus needing to go higher (because of the greater extent of the atmosphere) and faster (because of the higher gravity) before reaching a stable orbit. Eve is the hardest place to land and return from...although strictly by virtue of the fact that you can't land on Kerbol or Jool. I can't say for sure that the number's accurate, but given the atmospheric and gravity characteristics I wouldn't be at ALL surprised if it were HIGHER than that.

Make sure you installed X4R1 (there is no 4.0) by dropping the Innsewerants Space Agency folder into gamedata, and that there's no old bits left in <KSPRoot>/Parts or <KSPRoot>/Plugins The X4R1 version works perfectly fine in the current version of the game if you install and use it correctly. I've yet to see a single instance of an actual 'problem' with it that wasn't caused by user error. And as the first post states, he's not listed a license, thus making the license by default 'All Rights Reserved'. Anyone but Innsewerants distributing modified versions, derivatives, or even unmodified versions of any part of Mapsat is consequentially a copyright violation. As such any 'fixes' to 3.3.4 would have to be completely separate and include no code from the original, and also not include even unmodified bits of the original.

What happens when you go off the end of the runway? It's elevated quite a bit at the far end, so you'll at least briefly be airborne, even if you can't get the wheels off the ground normally. What happens then is generally indicative of what's causing the problem.

I've mentioned TWICE now that Multiwheels have a much better traction model than the stock game already. As such it's apparently possible to do via plugins. I've actually debated trying to modify the rollkage wheels to work with the multiwheels system, in hopes of getting the benefits of both, but I have some lingering doubts as to if I could pull it off and if it would actually help. I have no idea what a lot of multiwheels' extra stats do.

Well I'm trying to limit damageability and weight, and make it look halfway decentish, in roughly that order. Rockets and landing legs don't work very well for any of those. Sliding and fishtailing ARE realistic at speed/with enough power, but only after a certain point. That's the bit I mentioned with multiwheels: TT did something through his plugin that not only has the wheels powered by separate engines (Liquidfuel/Intakeair, Monopropellant, or Electric), with the power and speed scaling according to how many/what size you added, he got them to have a more realistic grip model that only slides if the lateral force gets too high (and makes smoke when it happens, too.) Unfortunately he's got the same suspension bug that the stock wheels have which is constantly sending my rovers out of control. The rollkage wheels are literally the ONLY wheels I've seen that have a suspension that actually works mostly properly (The bug is still there, but they've mitigated it somehow to such an extent that it almost never actually causes a problem.) What I'd really like is a combination of the multiwheels grip characteristics (and maybe the engine use) with the rollkage suspension, but there isn't a mod that offers that. Or anywhere close to it. The rollkage wheels are the closest to useable I've seen yet, though. And there's presently no way to edit the grip on wheels, either, so I can't really do anything on my end. Thus the post.

I've been playing with this pack, and I love the suspension on the wheels...but why do they have so little grip? It can barely climb any kind of slope because the wheels slip. I can turn in place with my reaction wheels with the brakes on. Every design I've made with the rollkage wheels has been prone to fishtailing, frequently uncorrectably (steering in either direction does nothing and it continues to fishtail, until you basically come to a stop.) and I just now got this shot of it sliding down a hill with the brakes on: If they had just a bit better grip, or something like multiwheels does where they only start to skid when the force gets high enough, they'd be all but perfect. The fact they don't send my rovers tumbling out of control and then end up snapped off is a big, big plus though.

Some things to keep in mind: KSP's drag and lift models are not aerodynamically accurate. The drag model in particular uses the weight of the part multiplied by the drag coefficient (which is what the 'drag' stat is). One side effect of this is that all parts produce drag regardless of position, based mostly on their weight. So things that are normally used to reduce drag at the expense of weight, like nose cones, actually INCREASE drag. The lift model is similarly less than spectacular, and does NOT include stalling in any form. The most likely causes of uncontrollable Pitch-Up are either the Center of Mass being right on/ahead of the Center of Lift, or Center of Drag being above the Center of Mass. Note that because of the way the game calculates drag that empty fuel tanks have less drag than full ones, due to their change in weight. Center of Drag being ahead of the Center of Mass can also result in pitch-up in some situations, particularly while aerobraking/re-entering. This is usually caused by forward-mounted air intakes, exacerbated by having empty fuel tanks. What happens is, any deviation from straight forward is accelerated, as the too-far-forward center of drag suddenly has enough deviation from the CoM to start pushing the nose of the craft around. In such a case the craft will only pitch up if you're in a nose-up orientation to start with: If you're nose down it'll go down, if you yaw it'll turn into the yaw. In any of these cases without intervention it'll come to rest flying backwards. There's an addon called Ferram Aerospace Research that exists specifically to update the drag and lift models to be fairly realistic, but it requires much more attention to the aerodynamic qualities of your design, and most designs that work fine in stock will not work or will work poorly with FAR. It also makes nosecones a requirement for efficiency, and requires changes in rocket flight path to deal with the changed aerodynamics. A counter to all this is that it actually REDUCES overall drag, and in particular removes the link to weight. It also makes some changes to jet engines that limit your top speed to about mach 5 (1600 m/s, roughly), and reduce their overall power.

A lot of people use one particular low orbit most of the time, and if they're not careful can end up with a lot of junk in that particular orbit. Otherwise it's not particularly likely unless you've got just tremendous amounts of debris. In real life, when something gets hit by debris, it spalls off more debris, or in rare cases can actually cause the thing that got hit to break up entirely. In either case, but especially the latter, you get 1 piece of debris creating a large group of debris. In KSP, any impact is going to destroy both the impactor and impactee, and destroyed parts leave no debris. Which means the only way a collision can spawn more debris is if pieces of one or both don't actually hit/get hit by anything and go spinning off. Which is possible, but it's probably going to create at most a few dozen pieces of debris, versus the hundreds or thousands from a real life collision. Kessler Syndrome refers to a scenario where a part of Earth Orbit becomes so saturated with items, that when a collision occurs, the extra debris it spawns goes on to cause more collisions, which spawn more debris, which cause more collisions... It runs away out of control until everything in that part of Earth Orbit is smashed, leaving a fairly dense cloud of debris that's almost impossible to get through without getting hit. This is almost impossible in KSP, because things which are on rails don't collide with anything. This means, practically, that only your focused craft or anything within physics range of it (2.4km by default) can be hit by anything. To get an actual Kessler Syndrome, you'd need a massive cloud of multi-part debris and/or ships orbiting the world at a variety of inclinations at a given altitude. You'd then have to use Lazor plugin or something to extend the physics range to encompass at the very least a large section of that orbital space to allow them to collide. If you set it up properly and got lucky you might get part of the orbit-saturating cascade that Kessler Syndrome describes(there's going to be so much less debris created from each impact than in reality that you'd never get the full effect). There'd also be a fair possibility that so much of each bit that hit each other would be destroyed in the impact that it would peter out, too.

Eeloo's really hard to get to period. Not only does it have the most distant orbit, it's fairly highly inclined and not even close to circular. It also has no atmosphere and thus you can't aerobraking to help you get into orbit around it/land on it. All of this conspires to require an enormous amount of Delta-V. Also a fair amount of thrust: if you're coming in directly from Kerbin, there's going to be quite a large difference in your velocity when you enter its SOI (which is rather surprisingly large if the wiki is to believed). To actually pull into orbit around it is going to take a lot of Delta-V applied fairly quickly. What this means is that getting to Eeloo is a tremendous engineering challenge. Getting BACK is in some ways even more difficult. Simply put, there's no place in the Kerbol system harder to get to or back from than Eeloo. Though Moho's not easy, either.

Open Mechjeb's 'Utilities' window and see if the 'Prevent Flameout' line lights up when it happens. If so, what's happening is that you're pitching so hard that the intakes aren't facing into the airstream and start producing less intakeair as a result. Specifically, enough so that you'd flame out if Mechjeb wasn't throttling the engine down to prevent it.

If it is, it's a customized one, because it's got the same style and texture as the wings in the pizza pack here, which the default Pwings don't. I'm pretty sure it's not though, because Pwings is terrible for Deltas due to the way it scales. They end up super thick at the base and razor thin at the tip. It looks like it has the same scaling versus the tip as the wings in the pack do. Just a LOT shorter. Edit: Here's a mockup I made using the parts in the pack, to make it easier to see what I mean. It's easy to see in this just how much further out the wings extend, even though it looks like the root is about the same size (if positioned maybe a bit further back on mine.) You can also see the one in the screenshot from the first page is only using two control surface segments to cover the whole length and I've had to use three (The only longer one was far too thick, and clearly didn't match the original photo.) Edit2: Whoops, I think I read the numbers wrong. What I'd be looking for then would be a 3x4 Wing2. Or maybe even a 4x4 Delta.

I'm pretty sure I have seen ones that explicitly waive all rights, but I didn't say it would *work*, I said I thought some idiot might *try* it. If it doesn't work for some of them, well hey.

I have to ask...what wings are those? It looks like the ones in this pack, except much shorter and steeper. It looks something like what I expect a 6x2 wing2 would look like, but there's no such animal in the pack?

Actually, there might technically be limits to that as well. The more strongly copylefted open source licenses, such as GPL, frequently contain requirements that any derivatives be open source as well, or somesuch(And in some cases, also require that the source be included with it). I'm not a lawyer, but it seems to me that if you used a license with a provision like that, someone might be able to try to argue that any updates you made to it were 'Derivatives' and thus required to be GPL licensed themselves. I don't know how well such an argument would hold up, but it wouldn't surprise me to see someone making it. If it did hold up, the only way to move forward with a more restrictive license would be to abandon the old codebase entirely and start from scratch. You might be able to do a dual-licensed setup where you have new, restricted licensed code that hooks into the old code, so that any additions or changes are in a separate, non-derivative codebase.