FlexGunship

Did anyone else notice that there were no "Day 2" or "Day 1" feature videos?

There's a program called Deep Freeze that does that. It was on all the lab computers when I was in college (almost a decade ago). There was an encrypted copy of the hard drive image stored in a non-bootable partition. At boot it would wipe the primary partition and restore the image. Plenty of people lost a lot of work. And it was impossible to get Windows security updates. But I'll be damned... We never had a virus for more than ten seconds.

Ablative heatshields only work in an atmosphere, under high temperature, and with strong convection currents.

Uh. This is awesome. Can't wait to use it. I can hear the irony already: "I got laid off and they hired someone younger and cheaper to do my job... got home, played KSP, fired Jeb and hired a new guy for less money."

I sincerely wish this were an option in the stock game. The difficulty and realism are SO SO SO SO welcome. I'm thrilled with the decisions I'm forced to make and love the fact that, out of the realistic physics environment (NEAR and 64k) suddenly real-life rocket designs emerge. Turns out the Atlas V 5xx configuration is really smart! It's pretty close to an optimal cost/weight/payload solution in KSP now. I have similar complaints as above... terrain geometry intersects with my Kerbals sometimes. Would love to see this solved. (Also, the height-map change could probably be included by default. Bodies are too bland when stretched out like this.)

Special request: I'd love to see more "unpainted" tanks (i.e. shorter 2.5m and 3.75m tanks). Making them lighter then the painted ones is a really neat idea. REALISM FTW! Also I'd like larger versions of the 1.25m tanks. I know these are "bland" but I love the authentic look I get when building with them.

"Funny, the meter on my capsule tops out at 15Gs... not sure how many I've experienced," Jeb.

Just a simple re-bump for this request. Sorry to be a pain. Fine Print is a must have for me; love it! But I'd like to explore resized systems. Being able to change atmosphere altitudes seems like the only inhibiting factor. Being able to change this in the config (manually) would be super helpful!

[FEATURE REQUEST] In the config file, I'd like to be able to change the defined atmosphere height. With the new 64k mod the atmosphere is at 100km. Many contracts become impossible as a result (i.e. sub-orbital @ 80km; orbit @ 90km). Thanks for a must have mod.

OOOOOHHHHHHHHH In the spirit of Halloween I've resurrected the oldest post I could find!!!!!! SPOOOKY!!!!!!!!!!!!!! Happy Halloween!

Woohoo! Proper bug reporting saves a mod (and the mental state of a modder)!

No kidding... I strongly suspect there would be a lot more support if everything came in this way. Have you tried removing the *.dll and leaving the parts intact? Some parts may fail to load their respective modules, but I believe you should still be able to play the game.

Removed from the template.

Here is a sample bug report template modified for use on this forum. Try it. Use it... LOOOOVEEEEE ITTT....

This is Ferram's code (from the source provided in GitHub): public static bool IsWin64() { return (IntPtr.Size == 8) && (Environment.OSVersion.Platform == PlatformID.Win32NT); } public static bool IsAllCompatible() { return IsCompatible() && IsUnityCompatible() && !IsWin64(); } He's doing two things here: Firstly, generating a boolean return based on system pointer size (64-bit OSes use 64-bit pointers) and checking that the Windows version is post Win32NT (all systems after Win98 seem to carry this platform ID). If both of these are satisfied, the return is TRUE (and you're in a Windows x64 environment); this is presumably to prevent a false positive on 64-bit Linux systems. Secondly, he is performing a logical AND of all of his compatibility checks. One of which is "!IsWin64()" or "is this system not Windows x64". You could simply remove that check and IsAllCompatible() would return TRUE even if IsWin64() returned TRUE. Remember that, if you do, you are not allowed to redistribute the mod per his license. If you need to ask "how do I do that" then you probably shouldn't be doing it and you should respect Ferram's wishes. I could do it in a heartbeat... but I choose to adhere to Ferram's rule; it's his mod. I hope he changes his mind. I'm using Win64 and KSP x64 and I sorely miss KJR and NEAR. A few bad eggs have ruined it for us all.

Sigh... this stinks for people who diligently reported bugs, posted log files, and were always consistently on their best behavior when using mods and Win x64. Maybe you could make users agree to a perma-ban from the forum for giving unhelpful feedback or complaining about the Win x64 version of the game inappropriately. Maybe the moderators would even support that. I have nothing but respect for what you offer Ferram. The same goes for Sarbian and stupid_chris. I'm sorry that SOME of us couldn't handle the responsibility of accepting your FREE LABOR... but there are definitely others out here that do nothing but appreciate and offer our best, most helpful, feedback and constructive criticisms. I'd appreciate it if you'd reconsider.

Adjust your landing coordinates a couple of seconds to either side. That's all it takes.

Bug Report: (dev version #319) While trying to do a "land at coordinates" on Duna, if the orbit is low (I was at 65km) MechJeb does an initial de-orbit burn, and then turns to the anti-normal (normal-) direction and seems to burn until the ship is out of fuel. This happens even if MechJeb is given a full orbit to prepare for the de-orbit operation. After raising my orbit to 100km there was no problem. No crashes or anything. But I have a saved game to recreate if there's some data you need to debug this. The debug output didn't show anything but normal messaging in both cases.

Bug Report: After clicking the "show list of all parts" button, the action group selector list (the 1-50 list) closes and cannot be re-opened. Clicking the action group list button (example: "2: Main Solar Panel Toggle") does nothing. Double clicking creates the "no target" message (as though I'm double-clicking on empty space). I am running 1.15a. No crash to report, so I don't have a log file. The only message showing in the debugger is related to Ferram Aerospace. EDIT: Going back to the space center and returning to the ship in flight resolves this issue. Also happens if you hit the "Auto-Hide" button on the 1-50 list. No way to un-auto-hide. DOUBLE EDIT: I can also confirm that action groups NAMES and GROUP ASSIGNMENTS are not persistent after switching ships. The actual actions that are assigned to groups stay... so I just need to reassign them and their action group groups after switching vessels.

Fair enough, you guys know better than I do. Capsule drop shows about 120 m/s below 1km. And about 250 m/s at 3.5km. Maybe it's not a good test; but these numbers aren't impossible to hit at a TWR of ~1.5. Especially if you start your gravity turn early.

Um, while you're at it, would a low-profile 3.75m docking port be a tall order? They end up comprising a significant amount of a rocket's length if build in orbit. I have four of them on a three-part rocket right now and the docking ports, alone, are probably 30% of the overall length.

As of build #312 I'm seeing a similar problem to buil #305. It doesn't seem to be quite the same, because before it was almost a positive-feedback response. Now I'm seeing that in some situations early in the launch (near the roll program?) the pitch control goes OPPOSITE of the direction that would bring it towards the "navball ascent path". I'm able to manually correct with WASD and the MechJeb will resume normal ascent after that. You can actually watch the "steering needles" in the bottom left go the wrong way. Side note: this even happens if the program vector is perfectly aligned with the navball ascent path indicator... so even small adjustments from MechJeb cause the rocket to slowly go off-course.

It's handy to "automatically" throttle a main engine after SRBs are exhausted. I totally understand what you're saying; proper use of thrust limiters can balance stages for the most part. But for SRB heavy launches it's helpful... you don't have to adjust the thrust limited mid-ascent. I feel like, with MechJeb and NEAR (or FAR), if you design your rocket well, it shouldn't require any input between launch and stable orbit. This is the only piece missing for me.

This is brilliant! Thanks. ...now to cautiously transition from praise to a request... I would love it dearly if the "limit to terminal velocity" function worked with FAR and/or NEAR. Are there any plans to incorporate that piece?

#308 either has a new feature I'm unaware of, or has an additional bug. Since changing to #308, I am no longer able to see more than on conic patch. That is to say, if I have an encounter with the Mun, I get my primary (blue line) and nothing else. There is no secondary or tertiary conic showing the result of an SOI change. I went back to #297 (my go-to version) and my conic patches were back to normal. I added two "part only" mods that I did not attempt to uninstall for this test, so I apologize if this is unrelated to your update in #308. EDIT: To be clear... I did NOT test #305 for this. So I don't know how long it has been present. DOUBLE EDIT: Checked the KSP setting file and confirmed that the CONIC_PATCH_LIMIT is still set to 3. I uninstalled the two mods I had added. This problem does not exist in #297, but shows up when I use #308. So, I believe this bug was introduced between those two revisions. Current version of KSP is 0.24.2. The current version of Mechjeb is compatible with that. Either download an old version of MechJeb or get an updated version of KSP.