Rebelgamer

Running 0.1.11 Looked into the cfg for landing on planets and moons: PARAMETER { name = ReachState type = ReachState targetBody = Jool disableOnStateChange = true } PARAMETER { name = ReachState type = ReachState targetBody = Jool situation = LANDED disableOnStateChange = true

Not sure if this is just my install that's doing this, but there is an issue in the Grand Tour contracts that involve landing on the outer planets. Specifically, they want you "landed" on Jool.

To me, it makes them easier, as I get more time in the atmosphere to accelerate before having to switch to rockets.

About the Direct Cycle Nuclear Turbojet, it says it has it's own intake, but the only way I could get it to work was by adding a radial air intake. Is that a bug or just the description needing to be changed?

The last several versions of tweakscale had issues with reverting, parts would increase in mass, tank capacities change, etc. As much as I like the mod, if I have to revert for any reason, I would have to check every part to make sure they didn't change, which is why I've stopped using it.

I'm having the same issue, only part mod I have atm is real chutes, otherwise all parts are stock. I actually broke my save game when I tried to recover the craft, now Kerbin is gone, no buildings and only the esc key and contract button works... Here's the save files in question. craft file ksp.log output.log persistant.sfs Edit: Third game exit and reload got the space center back, will test some more to see what happens. Edit 2: Happened again with a modified version of the above craft file. Also, recovery of the craft is not necessary for the disapperance of the space center. All you have to do is revert to vehicle assembly, then exit the vab, and the space center is gone. Edit: 3 After more testing, I think the parachute fix is conflicting with Real Chutes. I removed the parachute fix and deleted the partdatabase file, and have yet to re-encounter the issue.

And a bunch of them at that, I think my longest build took 40 days or so, but I don't think I ever built anything requiring that many rocketparts in one go.

For windows, no, not until Unity 5 is released(and KSP moved over to it). You can try it, you personally may or may not have issues with it. I get random crashes myself, so I started running ksp x64 on a linux usb stick, perfectly stable, though I do use ATM just to speed the loading up.

It's definitely toastier now.

Last time I used it it started in the retracted state...

Try building it in the SPH, not the VAB, and rotate the bottom towards the front. Will come out more accurate than using the VAB inverted. If your using DRE, don't bother sweeping past 25 on the AOA, you'll put too many parts in harms way.

The 6.5.2 beta mentions it, though I haven't tested it to see myself. From the changelog: *Tweaked inflatable shield drag values. Should be less flippier.

Mighty1, read wiki entry on radiators, should explain how it all interacts.

It's 197, the mach indicator is saying .4, which would be about right for sea level. Though the speed at rotation was probably more like 180 or so.

The latest Unity 4 build has a fix in it for the full screen OpenGL issue, though how long it will take the devs to update KSP to it is another question altogether.

I'm pretty sure OSX is only 32 bit.

I've seen the same thing LameLefty, KSP is definitely more crash prone at lower total memory used than previous versions were, mine mostly start at around 3.1GB, though I use the dx11 switch instead of opengl for the slight speed boost(gl loads more into vram though).

The beta is definitely more dangerous than previously, just disintegrated a mk1-2 3 man pod on a 3.5km/s reentry with a pre-atmosphere pe of 40km, craft disintegrated before it reached 42km. The heat shield burned through the ablative material like crazy. Improvement over previously when I could pull off 6-7km/s 40km aerobrakes and only burn off 10-20 units of ablative, no more deep dives.

You only need one transmitter on your power/relay satellites, orientation of transmitter does not matter. As for the receivers, I use the US Robotics mod to put them on hinges so they can be rotated in order to maximize reception power. My last big power network(.25), I had 3 kerbin geosync relays, 2 more in kerbin's orbit, 120 degrees leading/trailing, and 4 around kerbol inside moho's orbit. The primary power generation came from an AM farm orbiting Jool, with 3 relays in a polar orbit to keep from getting eclipsed by a moon during a burn. Also had a generator on kerbin just for launching, though it didn't get used much, as my base on minimus didn't need it. Would have been a nightmare without EL\karbonite though, I couldn't imagine launching all that hardware from kerbins surface. Tighter integration with MKS/OKS would be great, though I think those have shifted over to the regolith\CRP and away from ORS, which is what KSPI uses. It always irritated me that there was both water and liquid water, but they weren't the same or cross compatible.

I had one that wouldn't rotate until it got above 175m/s, but it was more like a cruise missile than a plane...and it is surprising how many people forget just how big a difference in speed there is between m/s and mph/kph/knots. Users look at it and go, "it's only 120, that's not that fast".

Nice, and I see what your talking about too. I haven't really messed with the AOA setting too much myself. On a real aircraft you could probably do something like that where the entire surface moves to stay parallel to the airflow, which would be a lot simpler than just the leading edge. The only issue I could see with that would be ensuring airflow to the engines at high AOA's.

The biggest limiter would be the control surfaces on the leading edge. Usually that is limited to flaps only, the last aircraft type I worked on(depot level) the LE flap didn't drop until flap detent was between 2-4(full). Even then, movement time was about 20 seconds to move 6 inches vertically. I believe it has to do with the amount of force the airstream hits the leading edge with, trying to design an actual control surface that could move in sync with the main control surfaces would probably be too heavy to be practical. If you think about it, by mounting on the trailing edge of the wing, the surface only deflects the airstream, it doesn't have to bite into it. It's interesting that it works in KSP though, I'm going to have to give it a try. Edit: Just looked at your image again, If the surfaces were set to deflect upwards as flaps, it should probably be be pretty stable at high AOA's.

Some people do have graphical issues with it, but not all. I'm lucky in that regard, and it does run smoother than with -force-opengl for me, though it doesn't reduce the memory footprint as much.

Some users have issues without the -no-singlethreaded switch. Try without, see what happens.

The OpenGL performance issue is a known Unity issue. TBH, I don't expect a fix for Unity 4, not with Unity 5 right around the corner, which supposedly will have a *working* win64, but we'll see. Oh, and I only use the -force-d3d11 switch.