Brotoro

A quick look in the persistence file shows that your kerbal's ... is determined by a "gender" value (either Male of Female...I wonder what happens if I put in Kraken or something else)... But, alas, it appears that Squad has NOT changed the profession system (pilot, engineer, scientist) to be determined by a value in the file, so you still will have to mess with names to get the profession you want. - - - Updated - - - Why? They still will have some (as yet undetermined by me) delta-V capacity. - - - Updated - - - And there are interesting things like this in the persistence file: SCENARIO { name = ScenarioDiscoverableObjects scene = 7, 8, 5 lastSeed = 559298752 sizeCurve { key = 0 0 1.5 1.5 key = 0.3 0.45 0.875 0.875 key = 0.7 0.55 0.875 0.875 key = 1 1 1.5 1.5 } } SCENARIO { name = ResourceScenario scene = 5, 7, 6 RESOURCE_SETTINGS { GameSeed = 475746992 MaxDeltaTime = 21600 } } - - - Updated - - - Oooo...the NavBall is semi-transparent now. Niiiiiice.

My first test in version 1.0 did not go well. I installed Kerbal Engineer (since there was an update that supposedly works with 1.0), and the Jeb9000 and Bill9000 and Protractor parts (so that the ships with those parts on them could load, even though they don't have any MechJeb or Protractor dll to link to). The game loaded up OK, and showed all my old ships in the Tracking Station. But when I went to Laythe and started looking over the ships, the game hung (spinning beach ball of death..."Application Not Responding"...memory usage was over 3GB by the application according to the Activity Monitor). So I Force Quit and restarted KSP. This time I checked out one of the Laythe BirdDogs, which looked really strange because of the reworked parts. The Ram-Air Intakes are now big clunky things, and the forward-swept canards are no longer forward-swept canards, and the tail fin is different. But, if you look closely at the BirdDog's rear fuel tank, you'll see that the bug that causes certain parts to show up shrunken has apparently NOT been fixed (but hopefully the old fix that I've been using with the Module Manager will work again to fix this): Strangely, the jet engine was deactivated, but I reactivated it and tried an take-off run. The BirdDog was very slow in taking off, but it did get into the air...and then the game froze up again. Restart...try again...and again the game froze up after takeoff. So I restarted the game and decided to check out Duna instead. I went to the Duna Lander 1 (currently unmanned). Its rocket engines were still activated, and so I decided to try flying it into orbit. Lift-off OK (with the cool new dust effects...but I couldn't tell if they were red Duna dust because I'm colorblind). Started to tip the lander downrange...and, again, the program froze up. Memory usage over 3 GB. Application not responding. Alas. So now I'll try a new save to see if the few parts I have installed are what's causing the problem. And onward from there, to see if the old missions can be restored to usefulness. - - - Updated - - - Certainly liquid hydrogen is very low density and would require MUCH larger tanks. But the new Nuclear Engine still uses plain ol' high density liquid fuel (whatever that is). So designing a new Tug would probably best be done with aircraft Liquid Fuel tankage. Even though they have a higher dry weight than LF/O tanks...I expect they will still be better than using a LF/O tank that is only partially filled with liquid fuel. The question I'm interested in (for the sake of the old Tugs) is what kind of delta-V they can get now with the updated nuclear engines and tanks (partially)-filled with only liquid fuel. - - - Updated - - - Nice to know. Thank you! - - - Updated - - - Tugs would probably have to bring along LF/O tank payloads for the mission (instead of counting on mostly using the excess LF/O from the Tug's own tanks)...but it may be worth including extra Oxidizer in the payload to match any excess Liquid Fuel the Tug has available to leave behind). However, this whole equation is changed by the fact that we now have the in-situ resource exploration to fuel the distant exploration part of the mission...so Tugs shouldn't need to haul as much propellant along as payload.

So... the only way to use stock fairings well would be to enclose your payload AND orbital insertion stage inside the fairing so that the fairing base can be dumped as soon as possible? That's going to be a difficult design to optimize.

This is craziness. How could this have been missed? I certainly recall them talking beforehand about how people could use giant fairings, but they'd be taking a huge hit from the mass penalty.

Buffed? It got a mass increase and had its gimbal removed. How is that a buff?

Heat shields? The Mercury capsule heat shield (1.9 meters in diameter) had a mass of 272 kg. I'm sure we have lighter, better heat shields nowadays. So, no...not a ton.

Maybe the temperature tolerance for that part is set incorrectly. I'm not where I can check its config file.

Huh... Really doesn't LOOK like a part that should be overheating.

Also too bad he didn't notice that the VAB crew and mission controllers are all still male. Maybe some day they'll allow females in the mission control building.

Maybe they called it something else.

Too bad he didn't notice all the pretty clouds in the 1.0 trailer.

Nope. Just "Server Migration" here. You guys must live in a privileged land.

What's here? If you mean KSP 1.0...I'm still getting the Server Migration screen.

I don't know yet about the ISP changes, but I have heard that they've increased the mass of the nuclear engine from 2.5 to 3 tons...so I don't think they were looking to be friendly to the NERVA at all.

The first post in this thread explained the bug succinctly. Also, Harv has said that the bug was quickly fixed, but the fix won't be in version 1.0.

Wait. What? All the mass of the fairings is in the base part? Does the mass of the ship not decrease when you confetti-off the fairings?

Pol deserves a De-Bug...so that you don't keep violently exploding at certain places on its surface. But hopefully this got fixed in 1.0.

Eh...if I was concerned with the time aspects of insta-scan, I could put my satellite into a polar orbit and decide how many days I'll have to leave it sitting there before I allow myself to view the data. But it would be nice if it could do a partial scan of the planet in non-polar orbits (have it just show results for latitudes (plus and minus 10 degrees) covered by the scanners orbit. That way if you make it to some distant planet, limping in without enough fuel to get into a 80°+ orbit, you could still scan for the accessible resources under your orbit.

But apparently we can get an infinite number of these is a relatively confined area. Wackjob should go and fill the ring with Dres-moons until they start to clump together into a new planet.

Yeah...those are in nice, circular orbits around Dres. Certainly moons...not incoming asteroids. All in closely-spaced orbits. Maybe you could get something like that if Dres had a moon that was hit by a large asteroid and shattered, leaving chunks behind that either settle down into circular orbits or accreted together (or got flung out away from Dres, or smashed into Dres). Maybe. So, again, I wonder how many moons there are.

Eeloo needs GP2 to hug it in its gravitational embrace.

Or just fiddle with the number (probably have to restart) and look at an insta-scan of the planet to see what's where, perhaps?

I'm just going to ignore the name "ore" and picture it being whatever reasonable material I could be exploiting in a given location.

You mean it overheats after we stop running the liquid fuel through it?

What foolishness is this? Why would you design an engine that overheats during its normal operational envelope?