Nerezza

How does the plugin currently differentiate between interior and exterior sounds? Also, is it a bug that any audio muffles just above sea level, or is this by design and just something I don't fully grasp?

Unfortunately since the plugin was outputting 300 lines a second it was impossible to reproduce my issue. I did relaunch and just now get the approximate altitude things started working again, thanks to AVAS: the 2-300m call outs are muffled, but the 400 meter and above call outs are loud and clear. During this time, ASET IVA switches also make no noise and alarms are nearly impossible to hear. I also noticed that the issue doesn't occur while your spacecraft is in contact with the ground somehow, either launch clamps or touchdown. So the problem occurs only while airborne below 350-ish meters. The ASET IVAs I've had this issue with were the ALCOR advanced IVA, the Mk1-2 ASET IVA mod, and an IVA of my own making in the Mk1 Command Pod (using all ASET parts.) My mods list is a little long right now (trimming it up a bit this weekend) so I just dumped a CKAN list to copy/paste here: I marked the mods that add SFX with '>>'s.

I'm having trouble with my IVA's panel audio being muffled below a certain altitude, where I'm sure the audio sources shouldn't be muffled at all. I'm using IVAs with ASET props, so for example when I have AVAS announce my altitude at intervals, the first few (and last few when landing) call outs are muffled enough to be difficult to make out, yet when I get above a certain altitude the audio clips suddenly become crystal clear. This also affects the clicks of panel switches, and the sounds of various alarms coming on. Haven't pinned down the cut-off altitude yet, but I might be able to give a guess next time I launch with AVAS on.

Hello, I'm sure you've got your hands full already but it'd be nice if your LifeSupportMonitor could be expanded for compatibility with other LS mods, USI Life Support in particular since that seems to have become the new standard thanks to MKS. Aside from that, I also want to thank you for your work on this pack. I saw your new Mk 1 Lander Can and instantly fell in love, and now I'm using the Unity Editor (for the first time!) to overhaul my other stock cockpit interiors to use the lovely new not-completely-glass-cockpit assets. Definitely won't turn out as nice looking as your lander can, but thankfully it's not too hard to improve on the vanilla Mk 1 capsule Edit: Also, I'd love if "NASA_GaugeSngl_ABLATIVE" could display Deadly Reentry Continued's "AblativeShielding" resource which replaces stock's "Ablator" resource while using said mod. I wouldn't mind an alternate "NASA_GaugeSngl_DRCABLATIVE" to swap out via modulemanager in case of DRC, if it's not possible to make a single gauge display 'either or'. Edit 2: Strangely, the Ablative gauge worked fine with DRC in an IVA I'm editing right now, but it doesn't seem to work in the Mk1 Lander Can's ASET IVA. I can't investigate tonight since it's almost 2AM now, but seems to not work consistently for some reason. Edit 3: I've got a little complaint to make about your CRT Display part. I think this picture shows the problem well: The image in the spoiler is of the CRT in an IVA I put together for myself (though this complaint applies to your lander can IVA also), and as can be clearly seen the CRT's camera display is anything but clear to see. That's during a transition to the dark side of Kerbin, and not actually on the dark side of Kerbin yet. Even in ideal lighting conditions (mid day on the launch pad) it's next to impossible to see the camera display through the CRT's snow effect, so it probably needs to be toned down quite a bit. I'd suggest that the snow effect should never hinder the camera view, but still be just slightly visible for that CRT nostalgia.

@Beale: I actually didn't mean for the Tweakscale config to be added to the pack, just providing it if someone wants a copy. The real problem is the config that comes with Tweakscale is outdated. Looks like someone used to use numbers in part names but decided letters were better or something. Also, Pol is 0.625 and docks on a 0.625. Progress is a 1.25 and docks on a 0.625. ATV (forget what you call it) is a 2.5 and docks on a 1.25 was my point. I meant to say there's not a 1.25 form factor resupply vessel with a 1.25 docking port.

-snip- I decided it made for nice variety since it and the ATV share roles, but I went ahead and put together Tweakscale MM configs for it. -snip- I'm aware of that, but I decided I preferred the Pol as a 1.25m resupply ship, partially because the pack doesn't currently have one filling the role. I posted what I did in case someone else wanted to resize their Pol too. The real problem is the outdated tweakscale configs.

I was looking at some wikipedia articles to brush up on station designing, and discovered the Pol's real life counterpart, the Cygnus, would actually translate to twice the size of the Pol in the pack. I decided it made for nice variety since it and the ATV share roles, but I went ahead and put together Tweakscale MM configs for it. Note, I didn't put in checks for tweakscale so only use it if you have tweakscale (and MM): @PART[Pollux_Control_A] { MODULE { name = TweakScale type = stack defaultScale = 0.625 } } @PART[Pollux_Engine_A] { MODULE { name = TweakScale type = stack defaultScale = 0.625 } } @PART[Pollux_RCS_A] { MODULE { name = TweakScale type = stack defaultScale = 0.625 } } @PART[Pollux_Solar_A] { MODULE { name = TweakScale type = stack defaultScale = surface } }

I think you meant to post in the KSPCustomSounds plugin thread.

I miss this mod too. Glad to see it's being worked on again!

Using CLS and Realism mode on, I switched seats and closed the Ship Manifest window while the seat transfer was in progress. Ship manifest quit opening any resource windows afterwards (no crew, science, or fuel transfers) until I restarted the game. The debug console only had two Error lines in it: Error: Transfer State: Stop... Error: in RealModeCrewXfer (repeating error). Error: Object reference not set to an instance of an object at ShipManifest.SMAddon.RealModeCrewXfer () [0x00000] in <filename unknown>:0 It all looks like a long winded null reference to me. Thankfully the kerbal survived the transfer!

Edit: I posted a Ship Manifest bug in the wrong browser tab. As for bugs for this, my decouplers all say force -1 in the editor but they seem to work fine otherwise.

http://imgur.com/a/bckEN First off, I keep typing androgynous instead of non-androgynous Secondly, I had a REALLY detailed review of what I meant, until I tried to backspace delete a word, which instead sent me back a page and lost me everything I had written up. Basically, the bases of your docking ports stick out twice as far as the others in those pictures (the ATV craft in the first picture has a slight recess for the docking port) and the bulged sides never seem to fit my crafts. I was saying it'd be nice to have slightly altered mesh variants to make them slimmer top-to-bottom (slimline ports?) or not as round on the sides (maybe a taper? streamline ports?) as right now, the ports kind of stick out like a (very pretty!) sore thumb. The docking port on the Soyuz TMA is somewhat like what I think would be a good variation. Of course, it should be obvious from my pictures Bobcat has ports like that but someone forgot to make a drogue counterpart for those! As for your drogue, it's good in my opinion. There's really not much room to invert a docking port's mesh on just about any surface. Oh and, the medium universal port hovers above a few attachment points. I don't have a picture available with a good example, but a little structure underneath it like the one on your new non-androgynous ports would take care of those pesky gaps!

Your docking parts are great, but I do have one complaint. They always stick out very far (read: VERY far) from the node they're attached to! I think two more variations of both the universal and androgynous ports would be enough to satisfy me: Slimline, which would be a slimmed down variation sitting closer to the surface of their attachment point. And Streamline, the same thickness but without the bulged sides so they're just as thick but don't look oversized for the node they're placed on. This evening I'm going to try matching your non-androgynous ports with the Bobcat Soyuz docking probe. I really like the model and texture for it, but no one remembered to make the female counterpart!! I've been trying to figure out something else to use, and this might be it.

I whipped up something you might include in your next release: @PART[Tantares_Crew_A]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true impassablenodes = bottom } } @PART[Tantares_Orbital_A]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[Tantares_Orbital_B]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[Tantares_Parachute_A]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[Tantares_Port_A]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[Tantares_Port_B]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[Polaris_Crew_A]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true impassablenodes = bottom } } @PART[Polaris_Orbital_A]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[Polaris_Port_A]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[Polaris_Structure_A]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[Vega_Crew_A]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[Vega_Crew_B]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[Vega_Crew_C]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[Vega_Crew_D]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true impassablenodes = top } } @PART[Vega_Node_B]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[Capella_Structure_A]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[Capella_Control_A]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[Capella_Engine_A]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true //Special engine? It's docking enabled and has a weird connector thing. Honestly, I don't know what to think of it!! } } @PART[Capella_Mono_A]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[Alnair_Crew_A]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[Alnair_Crew_B]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[Alnair_Crew_C]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[Alnair_Separator_A]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[Alnair_Mono_C]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[Alnair_Orbital_A]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[Alnair_Orbital_B]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[Alnair_Port_A]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[Alnair_Port_B]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[Alnair_Structure_A]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[Alnair_Structure_B]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[Alnair_Structure_C]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[Alnair_Structure_D]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[Alnair_Structure_E]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[Almach_Crew_A]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true impassablenodes = bottom } } I took the original config from July, then rewrote it entirely because someone's been super busy in the past 7 months!! The Capella_Engine_A was the weirdest one for me, because it's got that docking port on it and I have NO idea how that's supposed to work, so it's set up to let kerbals go from end-to-end despite the monopropellant. The next oddity to deal with was TKS. The descent module has the heat shield, but it's on top of the stack. Ultimately, I found a drawing on wikipedia of how the crew compartment should've been shaped and decided there would be some way to transfer through that heat shield. Finally, the docking ports are crew passable as that was part of their design in real life, however the vanilla docking ports of the same size remain berth-only if you try to dock. Next up, the Realchutes config was also getting outdated and left 3 parachutes on stock modules for me so here's an updated config: @PART[Alnair_Parachute_A]:FOR[RealChute] { @MODULE[ProceduralChute] { textureLibrary = StockReplacement currentCanopies = Main chute } } @PART[Alnair_Parachute_B]:FOR[RealChute] { @MODULE[ProceduralChute] { textureLibrary = StockReplacement currentCanopies = Main chute } } @PART[Tantares_Parachute_A]:FOR[RealChute] { @MODULE[ProceduralChute] { textureLibrary = StockReplacement currentCanopies = Main chute } } @PART[Almach_Parachute_A]:FOR[RealChute] { @MODULE[ProceduralChute] { textureLibrary = StockReplacement currentCanopies = Main chute } } @PART[Polaris_Port_A]:FOR[RealChute] { @MODULE[ProceduralChute] { textureLibrary = StockReplacement currentCanopies = Main chute } } However, the Real Chutes config itself needs to be updated before that config will work! Look in the RealChutes folder and find 'Tantares_RealChute_MM.cfg' and replace the contents with this: @PART[Alnair_Parachute_A]:FOR[RealChute] { @maximum_drag = 0.32 @mass = 0.04 !MODULE[ModuleParachute]{} MODULE { name = RealChuteModule caseMass = 0.04 timer = 0 mustGoDown = false cutSpeed = 0.5 spareChutes = 5 PARACHUTE { material = Nylon preDeployedDiameter = 1 deployedDiameter = 30 minIsPressure = true minPressure = 0.01 deploymentAlt = 700 cutAlt = -1 preDeploymentSpeed = 2 deploymentSpeed = 6 preDeploymentAnimation = Alnair_Parachute_A_Semi deploymentAnimation = Alnair_Parachute_A_Full parachuteName = Tantares_Parachute_A_Canopy capName = Alnair_Parachute_A_Cap } } MODULE { name = ProceduralChute } EFFECTS { rcpredeploy { AUDIO { channel = Ship clip = sound_parachute_open volume = 1 } } rcdeploy { AUDIO { channel = Ship clip = sound_parachute_single volume = 1 } } rccut { AUDIO { channel = Ship clip = RealChute/Sounds/sound_parachute_cut volume = 1 } } rcrepack { AUDIO { channel = Ship clip = RealChute/Sounds/sound_parachute_repack volume = 1 } } } } @PART[Alnair_Parachute_B]:FOR[RealChute] { @maximum_drag = 0.32 @mass = 0.04 !MODULE[ModuleParachute]{} MODULE { name = RealChuteModule caseMass = 0.04 timer = 0 mustGoDown = false cutSpeed = 0.5 spareChutes = 5 PARACHUTE { material = Nylon preDeployedDiameter = 1 deployedDiameter = 30 minIsPressure = true minPressure = 0.01 deploymentAlt = 700 cutAlt = -1 preDeploymentSpeed = 2 deploymentSpeed = 6 preDeploymentAnimation = Alnair_Parachute_A_Semi deploymentAnimation = Alnair_Parachute_A_Full parachuteName = Tantares_Parachute_A_Canopy capName = Alnair_Parachute_A_Cap } } MODULE { name = ProceduralChute } EFFECTS { rcpredeploy { AUDIO { channel = Ship clip = sound_parachute_open volume = 1 } } rcdeploy { AUDIO { channel = Ship clip = sound_parachute_single volume = 1 } } rccut { AUDIO { channel = Ship clip = RealChute/Sounds/sound_parachute_cut volume = 1 } } rcrepack { AUDIO { channel = Ship clip = RealChute/Sounds/sound_parachute_repack volume = 1 } } } } @PART[Tantares_Parachute_A]:FOR[RealChute] { @maximum_drag = 0.32 @mass = 0.08 !sound_parachute_open !sound_parachute_single !MODULE[ModuleParachute]{} MODULE { name = RealChuteModule caseMass = 0.08 timer = 0 mustGoDown = false cutSpeed = 0.5 spareChutes = 5 PARACHUTE { material = Nylon preDeployedDiameter = 2.5 deployedDiameter = 50 minIsPressure = true minPressure = 0.01 deploymentAlt = 700 cutAlt = -1 preDeploymentSpeed = 2 deploymentSpeed = 6 preDeploymentAnimation = Tantares_Parachute_A_Semi deploymentAnimation = Tantares_Parachute_A_Full parachuteName = Tantares_Parachute_A_Canopy capName = Tantares_Parachute_A_Cap } } MODULE { name = ProceduralChute } EFFECTS { rcpredeploy { AUDIO { channel = Ship clip = sound_parachute_open volume = 1 } } rcdeploy { AUDIO { channel = Ship clip = sound_parachute_single volume = 1 } } rccut { AUDIO { channel = Ship clip = RealChute/Sounds/sound_parachute_cut volume = 1 } } rcrepack { AUDIO { channel = Ship clip = RealChute/Sounds/sound_parachute_repack volume = 1 } } } } @PART[Almach_Parachute_A]:FOR[RealChute] { @maximum_drag = 0.32 @mass = 0.04 !MODULE[ModuleParachute]{} MODULE { name = RealChuteModule caseMass = 0.04 timer = 0 mustGoDown = false cutSpeed = 0.5 spareChutes = 5 PARACHUTE { material = Nylon preDeployedDiameter = 1 deployedDiameter = 30 minIsPressure = true minPressure = 0.01 deploymentAlt = 700 cutAlt = -1 preDeploymentSpeed = 2 deploymentSpeed = 6 preDeploymentAnimation = Alnair_Parachute_A_Semi deploymentAnimation = Alnair_Parachute_A_Full parachuteName = Tantares_Parachute_A_Canopy capName = Alnair_Parachute_A_Cap } } MODULE { name = ProceduralChute } EFFECTS { rcpredeploy { AUDIO { channel = Ship clip = sound_parachute_open volume = 1 } } rcdeploy { AUDIO { channel = Ship clip = sound_parachute_single volume = 1 } } rccut { AUDIO { channel = Ship clip = RealChute/Sounds/sound_parachute_cut volume = 1 } } rcrepack { AUDIO { channel = Ship clip = RealChute/Sounds/sound_parachute_repack volume = 1 } } } } @PART[Polaris_Port_A]:FOR[RealChute] { @maximum_drag = 0.32 @mass = 0.04 !MODULE[ModuleParachute]{} MODULE { name = RealChuteModule caseMass = 0.04 timer = 0 mustGoDown = false cutSpeed = 0.5 spareChutes = 5 PARACHUTE { material = Nylon preDeployedDiameter = 1 deployedDiameter = 30 minIsPressure = true minPressure = 0.01 deploymentAlt = 700 cutAlt = -1 preDeploymentSpeed = 2 deploymentSpeed = 6 preDeploymentAnimation = Alnair_Parachute_A_Semi deploymentAnimation = Alnair_Parachute_A_Full parachuteName = Tantares_Parachute_A_Canopy capName = Alnair_Parachute_A_Cap } } MODULE { name = ProceduralChute } EFFECTS { rcpredeploy { AUDIO { channel = Ship clip = sound_parachute_open volume = 1 } } rcdeploy { AUDIO { channel = Ship clip = sound_parachute_single volume = 1 } } rccut { AUDIO { channel = Ship clip = RealChute/Sounds/sound_parachute_cut volume = 1 } } rcrepack { AUDIO { channel = Ship clip = RealChute/Sounds/sound_parachute_repack volume = 1 } } } } Finally, Fomalhut_Science_A is missing a remote tech conversion. In Tantares_Extra_RemoteTech.cfg I just stuck this on the end: @PART[Fomalhaut_Science_A]:NEEDS[RemoteTech] { !MODULE[ModuleDataTransmitter] { } } I decided complete removal would be best. My other idea was to make a 3km antenna, but that's so useless you'd be putting another antenna on the probe anyway! Well, there's my long post for the day. You need to make sure to bring up the missing RealChute configs with Chris, of course.

I'm on a laptop with an AMD A8-5550M APU with no dedicated graphics device (unless you consider the APU one!) The first time I tried this was a couple KSP versions ago, and it ran okay enough. Today was the second time I tried this, and it both looks and runs amazing! I use openGL and DDS4KSP + DDSLoader to save memory, and other than DDS4KSP's texture compression I don't adjust or resize any of these textures. Great job! My only gripe is that I would prefer a much darker dark side on planets, similar to Interstellar pack's dark side. Out of all the images from the Apollo missions, the ones of Earth's night side being almost impossible to distinguish from the darkness of space around it always stuck out the most for me. If I ever get sent to the moon, I'd probably spend my entire visit sitting on a rock and staring at Earth, it's just so beautiful!! Edit: Actually, I can't remember which EVE pack did the darker night sides. I could've sworn it was Astronomer's, but I can't find any packs with the pictures I remember. || E#2: It's actually from better Atmospheres. You can stand on the launch pad, look up at the Mun, and admire its waxing phase instead of seeing a big ball of gray. || E#3: Nevermind, I have absolutely no idea which EVE pack did that, but I still want it! :C Final edit: Please note the wonderful dark side you can find in KSPRC already. Yes, with just one quick rocket launch you are able to admire this excellent dark side that (for good reasons, probably) can't be seen within the tracking station! I am a derp. This pack is great

@Fox Loco If you're on Windows, check how much memory you're using at that point. I only have this problem when I try to use the 8192 textures, and it only stops when my memory usage would exceed 3.5GB if it continues.

I agree with Tellion. I wasn't aware this was still actively being developed when I'd stumbled on this a couple weeks ago; it definitely saved me time! I have two suggestions, though: - Resonant orbit calculation in an (n-1)/n way, where n is the number of satellites to put up. You can save fuel and time by doing only a single launch, placing your launch vehicle in a proper resonant orbit, and individually circularizing the satellites. I end up using this web planner to determine the best altitude for satellites and how much battery storage is needed, but work out the resonant orbit instead of using parking orbits and such. - Listing stats for RSS planets at the bottom of the existing list. Just because, of course Feel free to veto these suggestions, they're definitely not necessary and I think that being able to select multiple antennas is a more important addition than them anyway! ;P

Personally I'm thinking of just editing .cfgs and limiting myself to a few launch sites that NASA commonly uses, if I can find a good list of course.

[Edited complete rewrite] I didn't know spin stabilization would work in KSP, and I'd thought of trying it but never got around to it (mostly because of the bug I'm going to detail in a minute!) but I gave it a go and things went swell. This is the first orbit I've ever done in RSS, since I've never tried it before, and probably the part that had me most surprised is how rapidly you go from suborbital perigee-below-surface to orbital at the end of the burn. If I'd know how much only a little loss of thrust could affect the outcome of that burn, I'd have definitely tried spin stabilization earlier. Of course, I'd also been dealing with a bug where quickloading to reattempt things like that wasn't able to load the vessel. I launched multiple explorers just to retry and finally gave up to investigate the cause of the problem. I don't know what caused it exactly, but I did notice I'd forgotten to install the RSS Distant Object config, and I also removed FASA's reflection plugin because I don't even know if that works anymore. One of the things I found when I'd examined the logs was that Real Plumes' SmokeScreen configs threw constant streams of errors while I was burning every stage; and this is with an up-to-date SmokeScreen plugin. I even redownloaded it for the last attempt at loading the game, and a burn gave me a few thousand of those null exceptions.

Looking at the results of the real life Explorer 1 launch (from this page: http://history.nasa.gov/sputnik/expinfo.html ) and the results I'm getting from trying to mimic the launch using FASA's Explorer 1 after RO makes its changes, I'm not sure it's set up right. I've launched multiple times and haven't been able to reach orbital speed, or the speeds that the real Explorer 1 achieved.

Playing on 6.4x Kerbol with a freshly downloaded beta of DREC, I tried a reentry using just a Mk1 pod with parachute. My ablative shielding only lost 1 unit before I burned up and exploded. I'm certain I had a good angle for the reentry, and I'm about to launch back up there and try it again to get more details. This time I'll quicksave so I can examine what's going wrong here. Edit: To use this in 6.4x Kerbol it seems I need to do either both Alternate heating model and Alternate density calc ticked, or both unticked. In both cases, however, I'll go through an entire reentry burning off only 1-5 units of ablative shielding from the Mk1 Pod which I think is very unusual considering I almost hit the maxtemp 1250 limit on the pod.

I'm undecided if I want to install this or not. My mod list is longer than my arm and I'm somewhat concerned that there might be exceptions occurring often. The only issue I'll see is that I might try too hard to fix the bugs myself, and spend more time in an IDE than in KSP! Also, have you considered calling it ExceptionDetection?

I knew there were buttons in the cabin that did different functions, but I didn't know the cabin lights were toggled via IVA only and didn't think to push any of the buttons last night. I'll give them a try today. I wanted to keep the KSO as stock as possible and not integrate B9 parts. I'll put them on if I decide to stick with NEAR. Also, I like being able to switch shuttle names but having to load multiple 2048x2048 textures into memory just to do that really cuts into space for other little mods. Would it be hard to set up name switching with smaller textures via Firespitter?

Holy Jebedisus someone pinch me, I thought I just woke up but it looks like Helldiver's back. I surely must be dreaming still!! On topic: I did something semi-stupid and installed through the (old) .exe for .90 but I still made sure the dependencies were up to date. I never did get around to launching the KSO in .90 until last night, though, and there were a couple things I noticed immediately: The KSO Block 9 Stock craft in the .exe is missing most of its action groups, and I think the engine gimbals aren't trimmed for some reason. I checked the craft file in Notepad++ and I could've sworn they were saved trimmed, but they didn't load trimmed. The .zip I downloaded last night definitely has more action groups than the one in the .exe, but I haven't gotten around to loading it up yet. I think you should post the trims for the engines in the OP in case this stuff happens again. I think it's in videos, but I'm connected via 3G cellphone right now and can't look those up. Also, on the FAR patches by the community (this is for people who're considering FAR/NEAR) I got into orbit using NEAR with a bit of fiddling to make the gimbals right, but when I tried to land there just wasn't enough drag to do so. I got through reentry safely, but the craft's lift got it back up to 30K before it could slow down, and it got stuck at 1,700m/s. I got up, had something to drink, visited the bathroom, came back two minutes later and I was still at roughly the same altitude and speed. This was an entirely unpowered reentry attempt in NEAR. With FAR, the supersonic flight changes would've probably made me do loopy-loops above the KSC, followed by aerodynamically ripping off the wings and the back right landing gear, but it appears that in NEAR there won't be enough drag to land the KSO. The good news is, I got the KSO to fly stock even with FAR installed for everything else once, when I'd accidentally forgotten to patch the KSO to FAR the first time I tried this mod. I'm thinking it'll be possible to keep NEAR for my rockets and to set up the KSO on stock aerodynamics. I'm going to look into it and if it's possible, I'll note it here. That'd be having my cake and eating it too! Edit: Also, what happened with the cabin lights? I was a bit surprised when they didn't work last night, and when I was checking if the .cfgs in the new zips were different than what I had from the .exe (they were) I saw that the module had been commented out.

That makes sense. RPM's coded to turn off when it has no battery power. I never had this problem because I had set up my tanks to automatically have power added in. Speaking of RF though, I've gone ahead and pulled it from my install. I spent half an hour trying to begin designing a dedicated launch vehicle so I could begin with satellite and station deployments in a new career, and everything had quit working on me (couldn't change engine propellants or tank contents. When I could, I could add infinite amounts of fuel as long as I just kept pressing the button to add fuel..). I'm sure it's not Stockalike but the RF plugin itself, but I'm not really bothered by this issue enough to want to spend more time with RF.