tg626

I'll have to check, but I think they were bouncing without me using the jetpack, and certainly it was stowed on impact... EVA->plummet->BOING!!!->ragdoll for a few seconds.

While doing some experiments I discovered that a Kerbal can now fall from at least 10km high and survive! Do they have a higher impact tolerance now or is this a matter of their drag in the new atmo?

Excellent! Thanks for the pointers, I will look into that.

I'd be glad to have just the original texture extracted from it's .asset prison

Looking for a way to tell if an EVA'd kerbal is conscious or not. I'm working on my own derivative of an EVA parachute and I don't want the Kerbal to be able to deploy it if he/she got knocked out exiting the ship. While I'm at it, any way to force a kerbal to LET GO of the ladder/hatch?

(I name my contract grind satellites "KOSMOS [4-digit-random-number]")

I've never heard of such a thing, tho the idea is an interesting one... I often accidentally end up with multiple "MissionName I" craft in space because I forgot to increment the number after loading it.

Ok, just spotted the "does not apply to ejected kerbals" bit in the change log.... So, NM... Seeing as how that's the case, I believe according to your license that I could alter your DLL and release it myself, as long as I give you credit for the original work. (I also know that releasing the parachute part would require seperate permission from CardboardBoxProcessor) Is that correct? I think I may change the defaults and trim the extra functions that aren't EVA chute related - and if I like my result well enough, it might be nice to release to the players as mod.

Now I made a MM patch to add "ejector seats" to all command pods using the following: @PART [*]:HAS[@MODULE[ModuleCommand],!MODULE[ModuleKrEjectPilot]]:Final{ MODULE { name = ModuleKrEjectPilot MODULE { name = ModuleKrKerbalParachute //how much drag it has when fully deployed deployedDrag = 5 //minimum air pressure for deployment minAirPressureToOpen = 0.04 //x and y scale for when in semi mode... so the actual parachute area in semi mode is semiDeployedFraction^2 semiDeployedFraction = 0.0025 //thought it whould be nice if the chute was higher in semi mode semiDeployedHeight = 10.25 //time in seconds it takes to deploy, or to go from semi to full mode deployTime = 3.0 } } } Which works, as in Jeb ejects and Space+F pulls his rip cord, BUT... notice the wildly different values for deployedDrag, semiDeployedHeight, etc? That's what I have at this moment because I was trying to see if those variables were having any effect - they aren't. I delved into this because at this point Jeb descends at a VERY slow <1m/s with a fully deployed chute taking forever even at 4 x warp to reach the ground. Is this by design? Note I have NOT tried this test with a parachute that Jeb takes from the box but when I apply these values to the "ejection" part supplied in the mod, the result is the same - it's ignoring the values I set.

Seems to work just fine as is. The only "issue" is AVC complaining about it being built for .90 - and I think adding [COLOR=#000000][FONT=PT Sans] "KSP_VERSION_MIN":[/FONT][/COLOR] [COLOR=#000000][FONT=PT Sans] {[/FONT][/COLOR] [COLOR=#000000][FONT=PT Sans] "MAJOR":0,[/FONT][/COLOR] [COLOR=#000000][FONT=PT Sans] "MINOR":90,[/FONT][/COLOR] [COLOR=#000000][FONT=PT Sans] "PATCH":0[/FONT][/COLOR] [COLOR=#000000][FONT=PT Sans] }[/FONT][/COLOR] to the version file on GitHub would solve that. Meanwhile, we end users can supress that message by opening "RCSBuildAid.version", adding the section above, and finding "URL": "https://raw.githubusercontent.com/m4v/RCSBuildAid/master/RCSBuildAid.version", and changing it to "URL": "https://raw.githubusercontent.com/m4v/RCSBuildAid/master/RCSBuildAid.versionfoobar", or anything else that fouls the URL - if AVC can't find the online version file to compare, it treats it as up to date.

Well alright, alright, alright, alright....

I assume "X Component" = X Component of normal vectors? And in any case, can you show me to a resource that will learn me what "Y component of normal vectors" means?

Good resource! I use "DXTBmp" which goes back to my Flight Simulator days - it simply lets you open/save various formats and separates the RGB and Alpha Channels. For the part I was testing on (Turbo Nisu's big hemispherical tank) I found the following to be true bigTankCap.dds (made from bigTankCap.tga) needed an alpha channel added to it, which I made mostly black with a small bit of white for the "bands" around the edge of the tank. this was based on a guess of what would look good after looking at the stock X200-16 textures. I'm not sure what the Alpha channel is doing in this texture however. bigTankCap_NRM.dds (made from bigTankCap_NRM.tga) I had to move the normal map from the RGB to the Alpha (which made it greyscale) and then darken it a touch. I then set the RGB channel to the same grey color found in model001.dds texture of the X200-16 tank. I used the X200-16 tank as my research subject because Turbo Nisu's "BigTankCap" is *Clearly* intended to match the visual style of the X200 tanks. DXTBmp refers to the RGB image as "Norm" and the Alpha channel as "Trans". Based on my experiments so far, I have concluded: Diffuse DDS: [*=1]Norm (RGB) = visible texture image [*=1]Trans (Alpha) = ???? Normal Map DDS: [*=1]Norm (RGB) = Reflection/Shine (is this called "Specualrity?") [*=1]Trans (Alpha) = Bump Map

I have parts that the original author last updated in .24 - so far they have worked fine BUT, with the new fast loading DDS support I'd like to convert the textures to DDS. I already know how to flip and convert the diffuse TGA textures to DDS BUT there are also XXX_NRM.tga normal maps that I don't quite know what to do with. Do they need to be greyscaled? Do they need to be made the alpha layer of the diffuse DDS? Or do they simply need to be flipped vertically and saved as a DXT1 DDS file?

Trouble is I can't BUY an older version for him, and if he gets into it and stays with it, there may be a mods issue later on. I was hoping for some settings in the cheat menu to make it like the old souposphere... A realism setting would be nice (hint, hint) but at the moment there is no such thing.

There are many sliders and check boxes in the alt f12 menu. Is there a way to set them to get a more pre 1.0 aerodynamic behavor? As is I think it would be too daunting for my 4 year old grandson to play, as had been my hope....

Recall that the core of the r7 is a sustainer not a booster. It should be just barely abe to keep you from falling back down during it remaining burn after the strap ons are jetisonned.

Wait... so we can make the png files into dds files and they'll load? That's awesome if true, right now head loading is really slow compared to the stock dds textures...

Thank god.... I really missed this.

Where should the 2 config files in the "Extras" folder be put? "Gamedata/TextureReplacer/"? Meanwhile, I installed it (I've used it for a long time) and it looks like you've nailed it - as least as far as I use it. All we need now is for someone who made the "boy" heads to make new "girl" heads - which isn't you. I find the class suits invaluable, esp since there's nothing else to tell me what "job" any given Kerbal has... :/

Not yet, but a few interns had their tenure cut short....

Folks fighting the new atmosphere might find some helpful info here:http://exploration.grc.nasa.gov/education/rocket/bgmr.html

Set the atmosphere pressure to .5 and they pop at just over 4km. Which is fairly real life. You still give your crew whiplash tho Or, get real chute where the deployment isn't instantaneous.

VOID is the mod you want I thInk.

Now turn on the Com and col and move the fins till the col is just behind the com...