Tiron

After he resigned from NASA and ARPA in 1971, he taught Aerospace Engineering at the University of Cincinnati until 1979. Imagine not just meeting him once, but having him as a professor!

Not where I live you wouldn't... If it isn't cloudy, you're limited to just the major stars, and not even all of them. Some of the constellations aren't even entirely visible (Cygnus, for example). As for the moon landing, well...my dad was 9 and my mom was 6. Best I've got is that I saw Mir and the Shuttle go over once...

Ummm...he says he paid $18, and that looks like a store receipt not a steam one. I paid $18 from the store, and the price went up from that before it went on steam. That was back in like 0.16 I think, and it went up not long thereafter. I'm guessing it's just a really old email and the links in it are rotted, nothing more. That's actually not that uncommon, particularly with things like MMOs that go through their own launcher and don't rely on steam for updates. Other things do it too, particularly older ones.

Funfacts: There's a 'terminate flight' button in the tracking station that activates if your craft isn't landed on Kerbin. They added a new 'difficulty toggle' that enables or disables permadeath for kerbalnauts. While there's no UI setting to toggle it (meaning you have to manually edit the persistence file to change it), it defaults to 'off', meaning that 'dead' Kerbalnauts will come back to life after a period of time by default. In short, you could've just used terminate flight, at the cost of temporarily not being able to use the six Kerbalnauts onboard.

Because certain cities are just not attached to the real world?

Only relative to the planet itself. You're still going around the sun. Luckily unlike the real world the Sun isn't moving within the galaxy, and the galaxy isn't moving within the universe, so that's all there is to it.

It's SAS equipped but the SAS isn't on, because I rebound the rover controls to IJKL, which is how I discovered that the Rover Controls don't override the SAS attitude lock setting. If you've rebound them, the SAS will fight every course change you make, so it's off, and its torque on a separate set of keys, so I'm pretty much completely sure it's not that.

Oh I know that, and I'm certain it's not related for a simple reason: I've actually hit higher speeds going up steep slopes than I can on a flat. I mean, on a flat it tops out generally at 22-odd M/S, maybe 23 with a slight downslope. It's easily overtopping 30 m/s going up steep slopes, and showing signs that it'd go even higher if allowed. It's basically acting like it's going downhill when it's going uphill... And it seems to handle absurdly steep slopes too. It's like an uber-Mako!

Right click on it in your library and hit properties, go to the 'Betas' tab, and select 'Previous Stable Release' in the dropdown box.

Well they ARE falling! Also, you can edit the courage values in the persistence file directly, if you want. It's really not hard. It's labeled as 'brave'. It'll probably be a really long decimal on randomly generated kerbals but don't let that intimidate you, the big three all have values that only go out to a single decimal place. It acts like it's a percentage, so don't go higher than 1.0 or lower than 0.0.

Reminds me of the Cuttlefish lander for the old Bigtrak Rover. And yeah, keep in mind that with the current drag model every extra part adds more drag as well as weight (actually the amount of drag it adds is based on the weight of the part modified by its 'drag' stat). Nosecones and fairings look good, but they reduce your rocket's capability. Unless you use FAR, then they do help, so long as it recognizes them correctly (I think rpayne was saying it doesn't for Novapunch's fairings?)

Beware! By default, they will respawn after a time!!! if you really want them gone permanently you could always hack them out of persistent.sfs... or turn on the 'permadeath' setting in there.

I've fiddled with it before, just not much with individual vessels. Mostly I just resurrected Jeb... There's a reason there's so many conditionals in there. Craft editing I've done some pretty significant stuff, though.

Given the size of the bin, I think they'd need to be inflatable or something...

It depends on a lot of things. What OS are you running, is it 32 bit or 64 bit, how much RAM do you have installed? How much RAM does your Vidcard have(If you're on a 32 bit system)? If you're running on Windows 7 64 bit you can in theory run right up to the full 4 GB if you have that much free (which realistically would mean you need at least 6GB actually installed), because that's what WoW64 gives it if it's got the Large Address Aware flag set (otherwise it's limited to 2GB, I believe). That's one of the advantages of running on a 64 bit windows system: even 32 bit programs get access to more memory because they don't have to share their 4GB with the OS. Although the 4GB limit for 32 bit systems is a bit silly anyway... it's enforced as a licensing restriction by Microsoft, allegedly because of compatibility problems but I suspect probably more because it gave them another thing on their 'list of reasons to upgrade'. In order to use Data Execution Protection (under any of various names), they HAVE to enable the use of Physical Address Extension, which on an x86-64 processor gives access to up to 48 bits of physical address space (enough for 256 TB). Windows Server 2003 Datacenter edition uses this to support up to 128 GB of RAM on the 32 bit version. Microsoft disabled the ability to use it to raise the amount of memory above 4GB (including video memory) on 32 bit consumer OSes starting in XP service pack 2.

Actually, I did. I cheated the gravity off (and infinite fuel), used a couple of little radial engines to fly it over to about where I'd been landing at, then flipped gravity on and infinite fuel back off and used the parachute it already had for emergency airdrops to land it. Proceeded to verify the issues still happened and posted it in the bug report forum. If it wasn't such a short distance, it wouldn't've worked, though. Well it'd work, but I'm not sure I'd suggest that for most users. Persistence editing is a fiddly and fickle beastie, and the game doesn't handle errors in doing so particularly well. I don't know about the persistent.sfs file, but in .craft files it actually stores all the location info for each part independently. I haven't done much in there vessel wise except to occasionally delete things, so I can't say offhand if it does that in the save file as well, but since the structure for a vessel appears at a glance to be basically identical to a craft file, I'm guessing it probably does. Which just makes it that much harder. It'd be easier to just delete the mod parts off the craft, assuming none of them are structurally significant (Like with my rover, where it's just a few scattered surface mounts), and load the existing save file on a stock install. Trick there is you have to get every reference to the deleted part, which is usually just on the part it was attached to. If it has any 'child' parts, you have to delete those too, and all THEIR references (Struts and fuel lines would be the big culprits here).

Well, that's most of my point: They really ought to make an exception for hyperedit, or build similar functionality in, to go with this policy, so that it isn't quite so hard to test something that has to be done in a particular spot. I've never been to Eeloo myself, it's just kinda the 'worst possible case' where having to redo something stock can be just devastating.

I didn't include that since they say they'll close threads that don't follow the guidelines, so I'm presuming that if you continually ignore them you'll end up getting banned from the forums sooner or later, or something. I DO find it hard to believe that all five of the not-me people that voted don't use any mods at all. The way the guidelines are phrased ANY mod at all counts.

Except that's rather bad for the game, isn't it? If people encounter bugs and then don't report them? That's kinda my point. Making it very difficult to report certain classes of bugs is a surefire way to make sure those classes don't get reported much, and I don't think any of us want that. I certainly don't. But location specific bugs have exactly that problem with the new policy. BTW, the hack gravity thing unsurprisingly worked, and I'm once again driving up mountain slopes at 30 m/s.

I'm not the one coming into a thread trying to derail it with a confrontational tone. I *am* halfway there, actually (maybe more than if this works), but that's not the point. If you found a terrain issue on Eeloo, that seemed to be specific to Eeloo, would you reinstall the game and redo your entire mission entirely stock just so you could report it? Maybe I should make it a poll. Edit: Made it a poll.

I'll try to mock that up real quick, because larger docking ports isn't working...I can get the port to lock on, but it either rips it right off the rover, or in the last run, gave the plane such a strong nose-down tendency that it literally couldn't fly (I'm guessing some kind of clipping problem). Edit: My real problem here is that wouldn't really work if the location you had to reach was on another planet. Or on the other side of Kerbin even, probably. It ONLY would work because the point I need to get to is so close. I just don't want there to be tons of unreported bugs because going stock and then duplicating it is too hard and takes too long...which WILL happen with the current incarnation of this policy.

Why should a normal user have to do tons of unpaid work to satisfy the dev's requirements? It's not fair for the devs to have to support mods, but it's equally not fair for the users to get stuck in a situation where they have to do hours of work before they can report a bug. Neither fact changes the other. The simple fact is, right now: If you simply uninstall a mod, any craft containing parts from that mod will be automatically deleted the next time you try to play, without a prompt or opportunity to try to correct the issue. It can take literally hours or days to reach a given location in the game, and it's difficult to reach some places at all with the stock navigation UI without doing a lot of extra work to work out the angles and such. The only method that allows you to bypass the former is, itself, a mod. Edit: What's needed here is pretty simple: There needs to be a way, in the game itself, to remove mod parts from an existing craft, and a debug function that allows you to easily move to a particular location. Or just make an exception to the 'stock only' rule for hyperedit, rather than building it into the game. Edit2: Okay, the docking port is NOT working... Edit3: Yup, docking ports do NOT work as a solution. I can't get them quite perfectly aligned and the magnet's not strong enough to pull it that tiny little bit into alignment, or so it would seem. So I'm back to square 1, where there's no reasonable way to reach the point I need to reach in order to duplicate the bug in the stock game.

Oh I know. But the simple fact is if the bug's specific to a particular location, expecting a user to go in and redo their entire mission all stock just to be able to report the problem is...a bit much. Imagine if the problem only happened on Eeloo? (and there are a few there, barely touched because nobody goes there.) You would have to literally spend hours reflying the mission by hand, doing calculations since you can't use protractor, etc. If it were like my craft where it was almost all stock to start with, it'd literally be easier to hand-edit the persistence file to remove the mod parts than to redo the mission stock. And if you mess THAT up even a tiny bit...bad things will happen.

Spending significant amounts of time redoing a system that works better than any stock method of doing the same thing just because it uses a grand total of 9 mod parts to form the connection. I could chop it down to three fairly easily. Chopping it down to none is not easy, because they're two seperate craft and... ...and what if I used docking ports...that could...almost work...errrrrr...sec.

That's the thing, the problem IS with stock parts. The rover's almost all stock, as is the carrier aircraft. Stock wheels, stock structure, stock fuel tanks, stock wings, stock control surfaces... The problem is it's designed to use KAS and docking struts to attach to the rear-center of the carrier aircraft, and redesigning it to attach with stock parts would be difficult, not least because they're two seperate .craft files at the moment, but also, I'm not even sure it'd work aerodynamically or physically. Which is only a problem because I need to get out of KSC in order to do the testing. The problem is literally only that it's too difficult and too time consuming to get the rover back to the same spot where it's experiencing the problems after going stock.