S1gmoid

Apparently Jeb took a chainsaw to an old Learjet to get enough cabin space in a rocket for the space tourists... PS. Everyone survived. Barely. Two of the three radial parachutes were lost during re-entry.

Regardless where they move it, it's still a bad idea. It's as if a game told you you cannot use a joystick to play until you unlock some in-game upgrade. Since it's been implemented, I guess someone liked the thought, okay, leave it in, just add a toggle button in the difficulty settings. Like "action groups always available" under "allow stock vessels", or something like that. ...please don't assume that I'm a complete muppet. Of course I'm aware of that. That is my problem.

I just noticed that action groups are disabled in carreer mode... It's a very intrusive change, and I personally find it rather un-fun - and I'm someone who likes installing mods for added challenge like deadly reentry... but for me, having to fiddle with the mouse in-flight is not a challenge, it's poor usability. It reminds me of this flash game where you had to unlock better graphics and control via in-game upgrades, but that was a joke. This here is not even funny. There is already a load of difficulty options. I'd risk adding another to toggle this shouldn't take more than 10 minutes plus QA, and it would improve the game a lot (or rather, fix a really bad decision that broke it). I'm sure there are many others who will second this.

Yea, the rule of thumb I got used to was "center of mass up, center of lift down, and it will fly okay".

AFAIK, 1.0.5 re-vamped heat... So yea, probably DRE needs to be adapted.

It might just be a mistake or misunderstanding on my part... yea I forgot the COL, but it seems to roughly correspond to the curvature (on this rocket it's shown to be slightly above center of mass). Now as I remember, back in 0.2x, if I put 4-6 fins on a rocket, it brought the COL right down to the fin. Here, it barely budges, and the curvature of the fins is much smaller than the curvature at the cabin, which might or might not be right. (Is there a good guide for doing transonic design for rockets? In .2x I thought I had it down, but now I seem to be having a harder time.)

Thanks for the hints... So far it seems that Analog Control was the culprit, but it only crashes in windowed mode. EDIT: I also got crashes I thought were caused by Distant Object Enhancement... But I still am getting them, although less frequently... it's the same malloc fail, too. Am I running into the 4GiB memory limit?! I don't have that much stuff... KSP(1081,0xa11401d4) malloc: *** mach_vm_map(size=67108864) failed (error code=3)*** error: can't allocate region *** set a breakpoint in malloc_error_break to debug It would seem this has occured before under Mono on OSX. It's most likely running out of memory, but why... Is there a leak in one of the mods?

Screenshot here. This seems totally different from what I remember from 0.2x... And it doesn't even look correct, but please correct me if I'm wrong.

Indeed! I second this bug, it's happening for me as well. Either that, or the center of lift calculation is somehow off? When I put a basic first tech node crew capsule on the rocket, I get a HUGE effect on both the FAR profiles, and the COL too. Back in 0.2x FAR, when I put 6 fix on a rocket, it always brought the COL down nice... Not any longer, as long as I have a pod on. Is this as intended? There used to be separators that meshed nicely with the heatshield on the capsule, but I can't find those parts any longer... but I wonder if that miniscule gap warrants such a gigantic effect. Also, this might not be a FAR issue, the entire VAB seems awfully wonky... For example the engineer report comes up with absolutely wrong alerts all the time, like no command module (when I do have a command module), no parachute (when I do have a parachute), etc.

Oh yes, love standardized CLR types. Is the single-precision physics a given with Unity? I vaguely remember reading something about that, regarding the workarounds to fix the most glaring krakens... I wonder if they have anything on their backlog to improve this. (On x64, I'm assuming that using doubles should be just as fast as floats on x86.)

Am I right in thinking this is a floating point precision issue? If so, does running on 64bits fix it? (64bit single-precision floats as opposed to 32?)

After playing on Mavericks last autumn, without any problems at all, I have re-installed KSP (latest version 1.0.4 from Steam), and this time I'm running Yosemite. And I'm having the exact same instability problems that were described under http://bugs.kerbalspaceprogram.com/issues/3404. Randomly, upon scene switching (recover vessel or revert flight), the game will sometimes crash, or freeze with the "progress indicator" running, but nothing happening at all. This seems to happen on every other flight or so. The game is playable, but not very. Mods installed (via CKAN): Advanced Jet Engine 2.4.1 Analog Control 1.6.1 Animate Emissive Module 1.11 Better buoyancy 1.4 Community tech tree 2.1 Connected Living Space 1.1.3.1 Crossfeeds Enabler 3.3 Deadly Reentry Continued 7.2.2 FAR 3:0.15.5.1 ModularFlightIntegrator 1.1.1 Module Manager 2.6.8 ModuleRCSFX 4.2 Procedural Fairings 3.15 RealChute 1.3.2.3 Solver Engines Plugin 1.11 Stage Recovery 1.5.7 Tantares 30.0 Tantares LV 14.0 Could someone share some information about the state of the MacOS version? Reading up on the Internet, it seems widely accepted that it's unstable on Yosemite, yet the bug I've found is old (0.24) and closed (even though it perfectly describes my problems on 1.0.4), and there is little discussion here about OS X... Here's the log file.

Hey, Sorry I tl;dr'd the thread (it IS too long), and there was no mention in the opening post... how does 64K play with Realism Overhaul? (Or rather, is 64K a workable replacement for RSS in a RO install?)

I can second that. KIDS does truly weird .... to the jet engines in .25.

Is the Vostok launch vehicle planned too?

Hey I'm sort of curious about offset centers of mass and engine gimbaling. So I've read that a properly gimbaling engine can be used to overcome the problem that results from having offset centers of mass, such as in capsules designed for lifting re-entry. Now what I'm not sure I understand is how this will work with the navball and headings. So if I have my thrust vector right through the center of mass, that means thrust would NOT be in the direction of what I think KSP considers as "heading", or would it? That would pretty much make precision maneuvering impossible...

Okay I did a test Yesterday evening with stock chutes. I set the minimum atmospheric pressure to .5 (maximum), and staged the chute in orbit. It survived re-entry, and nicely opened when the craft was safely below the sound barrier. So chutes failing at staging time doesn't happen with Stock. I don't know about RealChutes because of stuff. (Also that it complains about not being compatible with Mac unity.)

This is a good place to start: Getting your project on GitHub

Speaking of RealFuels... are you guys aware of configs for the engines in the Tantares soviet pack? Not having seen any has been the main reason I've stayed away from RF so far. This might solve that when it's completed.

Hey I've read about toggle-able control surface slots in wings... Is that on certain wing types only? I didn't find it, even though it would be really awesome. Also, a thing I noticed when trying to work with swept wings is that unlike wings, control surfaces cannot be made asymmetrical (by dragging the tip in 2 dimensions). Instead I can only adjust their length. I think it would be a cool feature to enable that, unless there is real good reason for it to be disabled.

I don't know if this helps, but you should be aware that Squad part folders, file names and actual part identifiers are totally all over the place. You'll have stuff like "elevon1.cfg" containing a part named "SmallCtrlSurf" or somesuch. Find the battery pack, open the cfg file, look at the "name" field, that's what you need to give ModuleManager to apply changes to it.

There's the "stone skipping" effect you can read about when a spacecraft coming in at too shallow an angle will bounce off the atmosphere. I've never seen that happen in KSP (stock sized Kerbol, FAR and DR), I'm wondering if FAR is accurate enough to allow for that kind of phenomenon, or what would be needed to implement it. So far I've found that with ablative shields it's pretty much just about "don't come in ridiculously steep".

You can always use hyperedit...

I think it should be made a config setting. It would be a serious nerf (I'd expect comms delay on the computer commands, etc.) Speaking of time delay, I started wondering whether actual comms event horizon modeling would be fun. I mean, say if you have a probe out near Eeloo, and have a ten minute comms window, you'd have to send out the command BEFORE the probe is in the window, so it would reach it when it can actually hear.

Time seems correct. Direction is way off.