Cydonian Monk

I'm not 100% convinced of this yet, but there may be an off-by-one issue somewhere in the custom head texture assignments. It seems that all of my kerbals are getting the faces of the kerbal immediately before them in the config, except Jeb, who or some reason has decided to be old and grey. They do however report as mapped correctly when you log the mappings at Plugin start. Edit: Ok, not off-by-one (as it's only an issue with Kerbals without skins assigned), but instead seems to be an issue with what texture it's using as "default" for the skin. Might be a configuration issue on my side.

Thanks! Hoping to have the last couple bits of this up in the next few days. Wrap up the Jool missions then an epilogue looking at some of the older relics floating around in the save.

(Ok, so I decided to split this final update into two parts as it was getting larger than I care for in a single post. Besides, I feel like crud right now and the last thing I want to do is edit screenshots. We'll have the short report here where I wrap up the Eve Gambit's mission, and come back for the report on the Jool Expedition in the final post.) Heading Home with a Stop by a Rock It wasn't just vacation time for the Eve Gambit crew, and there were countless science experiments lined up for them by the gang at KSC. On top of that they were responsible for organizing data from the various probes in the system, trying to reestablish contact an older probe on Eve that had disappeared during Eve entry, and finishing the interior assembly work of the Eve Station. But time flies by when you're closer to the sun, and as their transfer window approached they bid their space hotel goodbye and set out for their landings on Gilly. Catching Gilly was easier than I expected. Gilly is so small with such negligible gravity that I could've made four or more inefficient landings with this lander. So I decided to send all three of the crew down for a visit over two trips. First up were Lars and Romon, the only scientist within a few million kilometers. This landing was so simple I decided to do it on IVA, much like I do with regularity on the Mun and Minmus. I somehow managed to land perfectly Between Two Boulders. Perhaps Lars will decide to host a parody talk-show here? Lars got out and shoved a flag into the soft and porous surface while Romon bounced off to collect a surface sample. I half expected Lars to bounce up into orbit when he planted the flag, but I guess those space boots have some mean cleats on them. "You don't so much as land here as you do station keeping with the surface," Lars commented while recording a transmission back to Kerbin. "The surface is a bit like pumice. It's still rock, but not terribly dense. As lite as we are the landing craft legs still push down through the top layer, and the lander continues to sway. We could probably take Gilly back home with us if we had a klaw or something of the sort." The two spent a few minutes on the surface, taking in the wonderful view of Eve, then shot up towards the Gambit. The rendezvous was easy, with the Gambit barely managing more than a few meters per second above 5. Next down to the rock were Lars and the engineer, Tomton. Tomton was a bit worried they'd forget him and force him to become "that other guy that went to Eve," but his patience was rewarded. Lars decided to stay inside on this landing and conserve his EVA fuel. Tomton was having perhaps a bit too much fun, bounding what seemed to be a quarter of the way around the large asteroid that is Gilly in a single step. After a few more minutes on the rapidly spinning rock they both decided they'd seen what they needed and went back to the Gambit. This time they only got within 1.5km to save fuel in the lander and EVA'd back to the Gambit with their pockets full of Gilly-ian pumice. Afterwards Lars remotely piloted the lander back down to the surface where it would remain. Gilly being as small as it is, there was no guarantee some that something left in orbit would still be there when you came back for it. (Even without N-body physics!) With the crew back in the Gambit everybody said there goodbyes to Eve and its pet rock and burned back for Kerbin. Aerocapture at Kerbin occurred several days later (unimpressive, really, and I didn't take a single screenshot), and they quickly set up a rendezvous for Kelgee Station. The plan was for them to spend the next several months in quarantine aboard Kelgee in case they had contracted some weird disease on Gilly, and then head back home to he surface of Kerbin. In the meantime, the samples they returned would be processed in Kelgee's lab. Home at last.

As requested: How I converted an old sandbox save to Career mode... with Science!

How I converted an old sandbox save to Career mode... with Science! "This Facility is closed." "You feel like you'd learn more if the Research Facility was open." We've all seen those messages in our sandbox games when we try to use the new science system. Frustrating, no? With that frustration in mind and the concept of my "cycles" already in play (where all Kerbal society resets, losing the knowledge gained by the previous), at the start of 0.22 I set out to convert my Null Cycles SandBox game to a Career Mode game. And it was remarkably easy. What you need to do this: 1) A Sandbox Save that has been updated to the 0.21 format. 2) A new Career Mode save created form the latest version of the game. 3) A text editor. I prefer vim on the command line (though I used TextEdit for this demonstration), but I'm a UNIX guy. Notepad or Notepad++ on Windows should work. Be careful on OS-X that you don't use a text editor that utilizes file versioning, as that really screws up KSP's load times. Make sure to back up your save before you attempt this, just in case. First, open your new "Career Mode" save file (persistent.sfs in the KSP/saves/<save name>/ folder) in the text editor of your choice. You're looking for a SCENARIO section named "ResearchAndDevelopment". In 0.23.5 this will be the first SCENARIO after "ProgressTracking", and on a fresh, stock save will look something like this: Or this: SCENARIO { name = ResearchAndDevelopment scene = 7, 8, 5, 6, 9 sci = 0 Tech { id = start state = Available part = mk1pod part = liquidEngine part = solidBooster part = fuelTankSmall part = trussPiece1x part = longAntenna part = parachuteSingle } } Copy the entire R&D SCENARIO element (as highlighted above in the photo) to your clipboard and open your old persistence file (persistent.sfs in the KSP/saves/<old save name>/ folder). You want to paste this R&D SCENARIO element just before the FLIGHTSTATE element, and possibly before any elements added by mods. Here, for example, is where it would be pasted in my Null Cycles persistence file (the highlighted line): Once you've pasted that in the last thing you need to do is go up to the top of the persistent.sfs file and change it to a Career Mode save. To do this you need to change the value in Mode to 1 from 0, and possibly rename the Title to CAREER from SANDBOX (that seems to be mostly cosmetic though), the highlighted fields below. That's it! Load your old save up and enjoy the new world that is the R&D Facility. "But what happened to all the parts I was using in the SandBox mode?" you ask? Well, you need to unlock those with Science! You can cheatsy-doodle your way to a max tech tree by granting yourself free science by editing the "sci = " field in the R&D Scenario, but where's the fun in that? If you've converted an old save where you've landed probes on lots of different planets, the odds are good that you have enough to just transmit your way to max science anyway. Enjoy!

Thanks for this update! Fixes all the issues I was having. Tested the merging of config file, and it seems to work perfectly. Makes it easier for me to keep the kerbal-specific textures across updates. Thanks!

This will help: normalmap

I've seen this issue as well with the new asteroids.... Doesn't seem to be an E/VE issue, but more one with the core game or another plugin causing a a null-reference exception that in turn causes the planet to not load. Oddly the clouds & lights are the only things that work right.

So I've attempted to build two different serial implementations for OS-X today: The one stripped form mono linked by Faark, and this one: serial by wjwwood, which is basically exactly what I wanted (a C-languge/C++ implementation of pyserial). I can get the unix parts of the wjwwood library to build without issue, until it tries to link, at which point it freaks out due to me missing some linker flag that I don't yet know about. (Apple really doesn't make stock OS-X friendly towards those of us that build things... at least things that aren't Cocoa.) The serial implementation from mono built perfectly once I did a bunch of legwork and cog greasing (mostly to get the above wjwwood library built). So we'll go with that. Next step is to test it and get the proper magical C# invocations and incantations hammered out, and then we might be somewhere. There are still some minor changes required for zitronen's plugin to get it to work for us UNIX volk, namely removing skipping the code that checks the registry. Once I get the serial implementation to the point that it works, and works properly, I'll [edit] see if I can make the plugin code platform-agnostic and then [/edit] send zitronen a pull request so the plugin can work for both Windows and OS-X without too much trouble. And maybe then I'll look at what the GNU/Linux folk need.

It actually happened in both cases, but yes - generally I only replace the suits. Strangely this wasn't an issue with Bill / Bob / Jeb who followed the same logic (but that may have been a fluke).

As of 1.3.4 I no longer get the proper "personalized" textures for Kerbals in the stock 3-crew command pod (and possibly the other pods - haven't tested). Those that do get their textures replaced end up with the suit from the Default directory. The textures are definitely loading, as they work and assign properly on EVA, but the crews inside the pod with specific suits are all producing the following NREs: [LOG 20:18:15.200] 04/05/2014 20:18:15,KerbalAlarmClock,Vessel Change from 'No Vessel' to 'Ptolemy 1' [LOG 20:18:15.225] [TR.TextureReplacer] System.NullReferenceException: Object reference not set to an instance of an object at TextureReplacer.Personaliser.replaceKerbalSkin (UnityEngine.Component component, .ProtoCrewMember kerbal, .Part inPart, Boolean isAtmSuit) [0x00000] in <filename unknown>:0 at TextureReplacer.Personaliser.replaceKerbalSkins () [0x00000] in <filename unknown>:0 at TextureReplacer.Personaliser.updateScene () [0x00000] in <filename unknown>:0 at TextureReplacer.TextureReplacer.LateUpdate () [0x00000] in <filename unknown>:0 [LOG 20:18:15.264] [TR.TextureReplacer] System.NullReferenceException: Object reference not set to an instance of an object at TextureReplacer.Personaliser.replaceKerbalSkin (UnityEngine.Component component, .ProtoCrewMember kerbal, .Part inPart, Boolean isAtmSuit) [0x00000] in <filename unknown>:0 at TextureReplacer.Personaliser.replaceKerbalSkins () [0x00000] in <filename unknown>:0 at TextureReplacer.Personaliser.updateScene () [0x00000] in <filename unknown>:0 at TextureReplacer.TextureReplacer.LateUpdate () [0x00000] in <filename unknown>:0 [LOG 20:18:15.289] [TR.TextureReplacer] System.NullReferenceException: Object reference not set to an instance of an object ... et cetera... I can upload an entire copy of the KSP.log somewhere if you'd like to take a look at it.

Sometimes I'm envious of those of you that get the output log.

No idea what that means, hope you can make something of it.They're Null Reference Exceptions. I've also seen these (by the several thousands per second), but I couldn't tack them directly to FinalFrontier. They were especially bad in the presence of the new asteroids. Also had a bunch of "Array index is out of range" at the same time. They all started to show up after a "[Orbit Targeter]: Target is null" message in the log. Still not absolutely convinced these are from FF though....

After running the numbers on the asteroid I diverted by kinetic impact last night I would agree it should break up in the atmosphere and produce little more than a fireball. But it could still cause some devastation. It's a "small" Class-E, coming in at only 1,344t, but must be nearly hollow as it has a radius from CoM of 25m (estimated from flyby photos where I "missed" it). Based on its orbit it was due to impact Kerbin at roughly 4,500m/s (relative to Kerbin) and at nearly 80° to the surface. 1,344t at 4,500m/s would release 13,608GJ of energy, roughly equivalent to a small North Korean Nuclear Bomb (3.25 kiloton). Given its angle of attack and velocity it's likely some of it would reach the surface, but with the low density much of the energy would be dissipated by the atmosphere as the rock breaks up. It might even break up once it gets deep into Kerbin's gravity... no idea. Should make for an impressive light show (and a huge compression blast), but I still wouldn't want to be standing at the impact site. In KSP it'd probably just bounce around a bit then glitch out and go join the Hell Kraken.

Tonight in KSP I tried to do something the physics engine didn't like... and it basically just said "no." Repeatedly. So much for smacking my 1.5t probe against this gigantic rock at 3800m/s.... I mean, I clearly hit the thing - there's a shadow! (And it passed right through the field of view and the craft... over several tries.)

Well then. My work here is done. Seriously though, I had also missed the hot fix. Probably because I never got a notification about it as I turn off the update checker (and every part of KSP that asks to use the internet... at least until Multiplayer happens). And that launcher thing has never worked for me in OS-X. After a quick download and copying a save from 0.20 over, I can confirm that asteroids do indeed spawn in old saves games when using the hot fix. A class C potatoroid spawned just outside of Kerbin's SOI almost at once. It also fixed my "Kerbals go permanent rag doll on EVA" bug... thankfully.

No, not at the moment. But I'll write something up this weekend when I get the chance. The layout of the persistence file is very intelligent for the most part and pretty easy to work with. No, I was thinking more of "docking port + structural fuselage (or box strut) + claw" from the stock parts, and then just clawing that piece from another ship once in orbit to provide a pivot point (at the "joint" claw). If you need to swap it out or grab it from a different angle once on the ground you could always claw onto another ship, detach the joint claw, move, re claw. May not work at all depending on the collision mesh of the parts used, though.

Does anyone know the mass of your typical Class-E "Rock the size of [Hockley] Texas"? I've not been out to visit one yet and they all claim to be 150t in the persistence file.... Would love to do the math on the kinetic energy.... Unfortunately at 150 tonnes and typical KSP velocities they wouldn't really do much more than scare a chihuahua.

I was looking at this last night. It would appear all you need to do is copy over the ScenarioDiscoverableObjects SCENARIO, and some potatoroids should start spawning. Haven't tested it yet, though, but based on tests with enabling research in my former Sandbox saves, there shouldn't be anything else to it. There appears to be a seed name/value pair in that SCENARIO, but it's name is an unprintable character so you /might/ need to use a "slighty-more-advanced-than-Notepad" editor, like Notepad++ or vim. YMMV. Curious - did you try "clawing" with a pre-rotated claw piece? Such as: you have an armature with a claw on the end that you then claw with another craft. You could rotate the clawed armature to an angle that would reach, say, the top of an aircraft wing, etc. Would allow for changing the "angle of clawing" in the field, if nothing else.

Well, the compensation is that I get to use it once we get it working.

Not entirely. Not yet at least. To give a bit of an update: I've not been able to get the gcc build environment set up right on my Mac, at least such that I could build the libs needed to hook into. That's something I was going to tackle two weeks back, as I /really/ need to build a couple plugins for Gimp (so I can stop using it in a VM), which in-turn needs GTK, which includes what I need to build the bits of serial code extracted from Unity. I'll try to get to that Saturday and see what I can see. I was having multilib issues last I tried, and it was doing weird things like mapping unsigned long ints wrong, among other weird 32-bit vs 64-bit stuff. (I swear I had all that up and working before Mavericks....) I did find my Arduino stuff while reorganizing a few weeks back, and I've been following the main thread for this to keep up... so I'm as interested as trying this as you. It's just a matter of finding the energy to grok code outside of work after having it thrown at me all day.

Nice! The next question is what do you do with the asteroid once you've caught it? I've not looked into NASA's disposition plan, but I would assume at some point down the road they'd want to either deorbit what they've caught (to prevent Lunar mascons from perturbing its orbit and possibly sending it crashing down to Earth) or sell it to be mined. Kicking up chunks of the Moon by flinging a big rock at it in a controlled fashion and observing the after affects would be a geologists' dream... but if they catch something valuable (say, a rock with mineable nickel), who knows.

Nice catch! I've got one of those E-class monsters on the way to Kerbin on an impact trajectory..... The plan at the moment is to divert and aerocapture. After that... who knows. Mine it for science?

Submersibles using an asteroid as ballast? Yes please! I wonder what the crush depth of a Kerbal ship is. Assuming you can get the thing slowed down enough to where an attached craft survived splashdown, that is....

A wee tiny little rock that is. Right out of the gate I've got a giant class-E planet abuser that's supposed to bounce off Kerbin and then hit Eve... from an orbit out near Duna. I'm doubtful I'll have enough parts unlocked to catch it when it gets to Kerbin, but I might have enough to swat it away. Or maybe I'll just latch on and ride it to the ground, Slim Pickens style.... Without knowing what's inside these rocks, it's possible they're more hazardous to the environment than the hardened cases of the nukes you just destroyed. The Magic Boulder would probably poison the air or water with its green-glowing-ness. Then again, even if that tiny rock you nabbed hit the ground at 100+m/s, the results wouldn't be pretty.