Starwaster

Probably B/W for the off icon (this is going on the in-game toolbar) with color on the on icon to indicate that.... it's on. Ideas: just the name or initials. It could also be a picture of a capsule, with the on icon having flames. (as much as 38x38 allows) I am partial to the SDHI shield, which previously I have resized duplicates to 3.75m and 5m. With Tweak Scale you could do it to arbitrary sizes. Installed mods: DR (latest version), PreciseNode, Chatterer, and BTSM. I had launched a Jool mission a few days before 0.25 came out as well, and everything worked as expected, so this appears to be something new. Aerobrake was performed on the night side of Jool with a periapsis of around 110Km if that affects things. I'll have to send an expedition to Jool immediately to investigate this. Though I have seen that NaN issue around Kerbin but I forget why..... most likely you got an error at some point after which the temperature was NaN. Might mean I have to put a check in for that and re-initialize the variable.

v6.1 *Fixed typos in SPP.cfg and Wings.cfg (some parts were not getting shielded) *Additional sanity check when raycasting for parts shielding parts. *Added logic check to make sure a chute was actually exposed to damaging temperatures when deployed *Groundwork for toolbar support. (in-game per save game difficulty settings coming soon) *No, you won't see anything but the code is in place. Also, please refrain from breaking this for awhile, so I can go spend some time updating a few other mods.... (well that was worth a try anyway... never mind)

Wanted: two 38x38 images to serve as button icons for Deadly Reentry. Could be letters (DR or DRE initials) if so Papyrus font recommended (do you have to ask why?) Or could be graphic images. (perhaps capsule undergoing reentry) One has to be the 'off' state and the other the 'on' state. Also has to use alpha channels to mark clear/opaque areas. (I'd do this myself but this is a new computer and it's lacking in certain developmental tools including a tragic lack of Photoshop)

Oops that's right I forgot about that. I don't *think* Bahamuto did anything fancy with rescaling... Could be wrong.

It's been a long time since a KSP update broke parts. As long as those parts don't incorporate existing parts (which might change and break the dependency) then they're going to be ok. The part where you have to be concerned is if this pack has any plugins it depends on. If those have not been updated they may not function. (some even deliberately disable functionality if you try to run them on a version of KSP they weren't compiled for)

Without a recompile, sometimes they won't load at all because they're looking for a specific version of whatever they were originally compiled against. If they do load, as long as nothing changed in any of the classes/methods they have to access then it'll probably be ok. Obviously YMMV and a recompile with the new dlls is the best strategy.

The odd thing is I've compiled that same code a dozen times and Monodevelop hasn't whinged once about the unused variable....

And a heads up to your heads up They fixed the rescale bug so your LV909 will be too small as configured. (removing the scale line from the MODEL node should do it) You're welcome. You sure you don't want to try my config?

Ugh this is a little odd. That's not quite the same error I saw before. So I went and loaded the game, found a part that was all white and checked the log to see what its error was. I can't find that error now and the part is logged as having compiled properly and its texture loaded properly. I did however find several of those errors for SDHI chutes. However, the log says earlier before the error that the texture loaded properly and the chute looks the way it should in the game. (fyi they're png not tga so I'm no closer to confirming or discarding my tga theory)

Well there is, if you try to deploy chutes into the fiery hot plasma bow shock. It's just that a tiny wee bit of logic is missing that controls when failure happens

I'm both, and that cat is not being eaten (p.s., you should use linked thumbnails instead, that's fricken huge!)

Careful, just replacing a dll can (potentially) cause problems if the plugin isn't recompiled against the new version (of KSPAPIExtensions). If it works, great, but just a caution. This is just speculation as I don't have enough empirical evidence but there's a problem with tga textures and KSP 0.25. And it's not 100% sure to happen every time for the same tga texture. Porkjet's Habitat pack has the same problem but sometimes it's one of the inflatable habs and once it was the base mount / landing legs. EDIT: I just realized I'm actually using .tga in one of my own parts packs extensively and I haven't seen it happen there once, so take the above with a grain of salt. It's just all I have to go on right now. (btw if you look at your output_log.txt or player.log you will see texture load errors for texture of the part that is all white) Are your engine nozzles sticking into the ground? They will produce no thrust at all if that is the case. Raise the rocket off the ground with launch clamps or put decouplers on the bottom of each rocket. (or at least enough to raise it off the ground. Even a fraction of a meter is sufficient)

Chutes: Found a problem that will be fixed soon. x64: There will be no x64 version because KSP x64 is too unstable to troubleshoot and isolate issues on. Sorry Maybe later when Squad has a stable version out. (you will notice that their download page states it is unstable. And in computer programs, unstable is not like the Marvel Universe where unstable means things like unstable molecules which lets superheroes have nifty costumes that don't shred when they use their powers. @Yellow Dart: try raising density exponent in 0.05 increments. (0.5 was found to be too lethal for a lot of people which is why it's all the way back to 0.85) here's a cute cat to tide you over until the next update. Eating spaghetti.

Indeed, that WAS truly the community. Cerebrate does not constitute a community and over the past 24+ hours has acted like he wasn't even part of this one. Yes, you're right, the license allows derivatives. What he did was NOT a derivative. It was blatantly circumventing Chris's measures that he put in play to disable the mod in a Win64 + KSP 64 environment. While simultaneously refusing ownership of the problem he was creating.. There is a way in which he might have handled things, if it had been a true derivative. I posted such here: http://forum.kerbalspaceprogram.com/threads/57988-0-25-x-Wenkel-Corporation-RealChute-Parachute-Systems-v1-2-5-2-09-10-14-dead?p=1462640&viewfull=1#post1462640 To sum that post up, MAKE it a derivative/ branch it off as a new mod, with its own thread and assuming personal responsibility and ownership of the situation. He chose another route instead, refusing any other course of action.

Does it happen only with pre-existing ships and or craft files? Or can you replicate the problem using newly created and newly launched ships? If it only happens with preexisting ships, try quick saving then exiting the game. Reload game and then quickload your previously saved game. PS. And Thanks for all you've done Chris. Sorry about what's happened.

I have no life and I must scream. I guess what I'm trying to say is, you have two ReflectionPlugin.dll floating around. (one in the top level of GameData) That could be the cause of the problem. I just checked this out and the plugin works in 0.25 (it would actually be a little weird for it not to. Really fundamental changes would have to take place in Unity or KSP to break this. Most of it is just stock Unity code with hooks into KSP events)

Hope this isn't necro posting but https://github.com/Starwaster/LayeredAnimations It extends the stock animator and accepts the same fields plus one other, layer, which you use the same as you would in the firespitter generic animator. (different unique layer for each animation you have on the part)

Sorry, I haven't had time to get to this plugin yet. It would speed things along if I had an output_log.txt file (or player.log for Linux/Mac)

Ok thanks, those should be fixed next update.

Yes, this is still currently functional as is. A proper recompile will happen sometime in the next day or so.

yes, sorry I meant to post earlier. There will be a recompile and update but I've been a bit busy with Deadly Reentry which I have recently taken over from NathanKell. DRE needs a bit of attention right now and Ioncross is still functional as is so it can wait a little bit. However, regarding spaceplane parts, it sounds like you are missing ModuleManager_Default.cfg which makes sure that all parts which can be crewed are equipped with life support module and supplied with O2 at a default level. You might want to reinstall.

Yes, you're in career mode. You need to unlock more MechJeb functionality. Not all of it is 100% functional in career mode. That is by design. You have to research the parts you want. The part that combines engine control with attitude control is the Translatron. I forget exactly where it is on the tech tree. Somewhere on the bottom row I think.

Why is that so unusual? No offense but you really need to read up on how a heat shield works because ........ (no never mind) Look, There are multiple schemes for protecting a vehicle from reentry heating and a single shield can use several of them. There are ablators, which help keep the shield from rising above a certain point by carrying heat away from the vehicle and forming a gas barrier that pushes the superheated shockwave away from the vehicle. That's the AblativeShielding resource. Then there is thermal soaking, which as the name suggest acts as a sponge to soak up heat. In DREC that's modeled with a high maxTemp rating. When the heat shield part's temperature increases past maxTemp, KSP (not DREC) destroys the part. Makes it explode. Most of the heat shields in DREC use both methods. The ablative material just keeps the temperature from rising above 300-500 or so. (RSS class shields peak higher and ablate away even more material and dissipate more heat) and the high maxTemp keeps it from blowing up too soon. So in that picture above, your shield is now rising above 400 degrees. It has a maxTemp of about 1800. (DREC leaves the maxTemp of heat shields alone) In summary, the AblativeShielding is NOT a 'life bar'. Ablative is just intended to keep your temperatures low. maxTemp let's it survive higher temperatures, hopefully long enough to get on the ground. (that part'll happen pretty definitely) Do you still think your shield should be exploding right now in that picture you posted? Here. Make a file in your GameData folder (or ANY of its subdirectories) and name the file suicide.cfg. Then edit the file and copy and paste the following code into it. @PART[SDHI_2.5_Heatshield] { @maxTemp = 600 }

I looked over a few of the parts and found the names to be the same. (cockpits, cargobays, a few others) However the craft files that SPP came with don't load. Says they have missing or locked parts. (and since it's sandbox, they aren't locked) Looking further, some names got changed. Minor things like a dot removed. (mk2FuselageLong.LFO renamed to mk2FuselageLongLFO, structuralWing1 renamed to structuralWing while structuralWing2 is not renamed) If you put the craft in the SPH folder and try to load it up, then bring up the debug window you can see what parts are missing because they are logged as errors. (i.e. [Error]: [shipConstruct]: Trying to load [sP+] Explorer - No AvailablePart found for mk2Fuselage.LFO) So if you rename those parts in the craft file, you can probably get them to load up but you might have to reposition some parts. YMMV.

It's really amazing what strange things you find in those pictures if you stare at them long enough. And of course there's some perfectly sensible explanation but to us, with no context, they're incomprehensible....