rifter

Unfortunately, mod parts are still tied to the nodes(but not visible within the nodes themselves at R&D), and as such show up in the VAB when the corresponding node is activated, but all of them are grayed out with the message "Part model requires an Entry Purchase in R&D". Since they don't show up in the R&D nodes that activated them, there is no way to add them without adding them manually to the tree.cfg.

Obviously, if it has SABRE in the part title, it must be part of the same plane, right?

It only weighs 5.46 with the heat shield configuration; even if I replace the weight of the heat shield with monopropellant (or something), the capsule is still going much slower than when it has the heat shield for the same point of re-entry. That is to say, I don't think the extra weight is the cause. Again, this is only when using FAR. Any other ideas?

Yeah, without a properly sized heat shield, deceleration happens normally for me on the kerbal X mk 1-2 pod. With the heat shield I'm still going over 2km/s around 20km altitude.

It sounds like you have an older version somehow? Those problem sound very similar to the ones that existed in version 2.2a or so? But yeah, I would check to see all the plugins that are installed are up to date (and not riding alongside older versions of the same plugins etc.), because that sounds like a borked installation.

What happens if you try just putting the config in? The latest FAR update is using Module Manager, and Deadly Re-entry also uses it, so there may be a version conflict? Try searching for other instances of the ModuleManager.dll in your ksp folder?

Drop both the file and the dll into the GameData/RemoteTech/ folder.

What sort of SSTOs are you using? I can easily get well over 1000 m/s in atmosphere (around 22-23km) without anything exploding, and then move up to around 30-36km for the last 1000-1500 of acceleration, where there are barely any re-entry effects. I mean, if I switched to rockets around 20km to try to reach the ~2000m/s necessary for raising my periapsis, I could maybe see enough heat buildup to cause explosions.

Out of curiosity, how did you arrive at a thrust rating of 300 for the radial PDE?

It really only becomes deadly at speeds in excess of low orbital speeds, that is > 2300 m/s or so. Try a higher apoapsis.

You could always just increase the atmospheric density by 3 orders of magnitude, or decrease the mass of all parts by the same

@PDCWolf Yeah, the same happens for me (strangely low temperatures on the leading edge). I found out, however, that all the heat not in those parts had found it's way to the other end of the rocket (engine facing retrograde on re-entry, so the top of the rocket). Also, even with infinite fuel, I can't make it back down the surface, since the heat doesn't seem to dissipate once the rocket is below a certain height (somewhere in the 30km range). Explosions from overheating and cumulative heat damage make up most of the rest of the flight. In the end, only a few (very hot) pieces crash into the surface, regardless of how slow the rocket re-enters. Reverting to 2.2 (from 2.2a) makes everything play nice again

The area of the map is around the KSC is the only place I think that works, and only there up to a height of around 1000m vertical. EDIT: Or maybe I just need to test more or something.

Option 2 sounds more fun to me.

So that's why whenever I pulled the nose up with the YF-28 at > 20km the engine output would suddenly shoot up. Mystery solved:)

That brings up an idea: as something heats up more and more, it becomes more vulnerable to structural failure under lower G-forces. This is all based on the idea that steel can still deform well below its melting point.

That's because it currently has no unique IVA, and the MK1 IVA is being used as a stand-in. As noted here and here , due to a ksp engine limitation, only one animation is available to a GameObject, so it now lights up rather than retracts.

One apparent bug (for me anyways): Deadly Reentry apparently causes an issue with the SABRE M engine of the B9 Aerospace pack (version R3). I documented it here, if anyone's interested. Edit: apparently it's ModuleManager's fault, not specifically deadly reentry. Sorry for the mis-report.

For some reason, Deadly Reentry 2.1 RC4 causes the SABRE M engine to not work. That is, on launch, the engine doesn't show the "Air" gauge, and has NaNU for the fuel flow (fuel flow only happens after being staged and any amount of throttle being applied). If toggled to rocket mode and back to air-breathing mode, the air gauge then appears. Unfortunately, when it is throttled up in this state, though the engine roars, no flame or heating effects occur, and though the right-click menu shows that it is producing thrust, and the resources menu shows it is draining fuel. Rocket mode acts the same way. I have tried modifying the .cfg for engine to be mostly identical to the SABRE S engine (which works just fine), however, this has not proven fruitful. Though it is probably not due to a bug in B9, I hope documenting it somewhere would be helpful to others who may be having this problem. On an unrelated note, apparently due to parts overlapping something fierce on the SCVD Vonnegut, the shielded docking port keeps freaking out and removing itself violently from the fuselage.

On my installation on Linux, there is a bit of a weird bug. In order to make the plugin work correctly, there needs to be a GameData/CrewManifest/Plugins/PluginData/CrewManifest/ folder (hereafter referred to as the CrewManifest folder) with identical contents (as in the contents on initial install) to the GameData/CrewManifest/Plugins/PluginData/crewmanifest/ folder (hereafter referred to as the crewmanifest folder) that is installed. If the folder doesn't exist, the game will create the folder on the first run after the installation of the plugin, however, it will not copy over the contents of the crewmanifest folder. Consequently, in-game the plugin will not appear at all (no icons at launch or space center). However if the CrewManifest folder does exist and has the contents of the crewmanifest folder and there is no crewmanifest folder, the plugin will appear in-game, but be missing its button textures (the missing texture icon takes their place). If both the CrewManifest folder and the crewmanifest folder exist and have the contents of the crewmanifest folder, the plugin works and the icons for the plugin display correctly. I hope this helps in tracking this (apparent) bug down

This config gives you sound (kinda), if you put everything in the zip GameData/SM-Pulse-Det-Eng/ folder and replace the cfg file. You need the Firespitter .20 pre-release, also. I haven't had much time to mess around with it. The config: http://pastebin.com/W8ARkVry

I recently have come across the issue that whenever I subgroup any lazors, I can no longer end the flight of any vessel in the vicinity (this includes going back to the space center). This has been tested on Linux x86, with Lazor System v26. Deleting the .cfg and .txt files in PluginData/romfarer did not fix the problem. The work-around is to put all the lazors back into one group at the end of use, at which point, ending the flight is again possible. The error in the log reads as follows: ArgumentException: An element with the same key already exists in the dictionary. at System.Collections.Generic.Dictionary`2[system.String,KSPParseable].Add (System.String key, KSPParseable value) [0x00000] in <filename unknown>:0. at Romfarer.Util.SaveKSPParseableRect (System.Collections.Generic.Dictionary`2 partDataCollection, System.String i, Rect r) [0x00000] in <filename unknown>:0. at Romfarer.CFG.onFlightStateSaveX (System.Collections.Generic.Dictionary`2 partDataCollection, System.String identifier) [0x00000] in <filename unknown>:0. at Romfarer.CFG_yellow.onFlightStateSave (System.Collections.Generic.Dictionary`2 partDataCollection) [0x00000] in <filename unknown>:0. at Romfarer.LazorSystem.onFlightStateSave (System.Collections.Generic.Dictionary`2 partDataCollection) [0x00000] in <filename unknown>:0. at ProtoPartSnapshot..ctor (.Part PartRef, .ProtoVessel protoVessel) [0x00000] in <filename unknown>:0. at ProtoVessel..ctor (.Vessel VesselRef) [0x00000] in <filename unknown>:0. at Vessel.BackupVessel () [0x00000] in <filename unknown>:0. at FlightState..ctor () [0x00000] in <filename unknown>:0. at GamePersistence.SaveFlightState (System.String saveFileName, System.String saveFolder, SaveMode saveMode) [0x00000] in <filename unknown>:0. at PauseMenu.draw (Int32 id) [0x00000] in <filename unknown>:0. at UnityEngine.GUI.CallWindowDelegate (UnityEngine.WindowFunction func, Int32 id, UnityEngine.GUISkin _skin, Int32 forceRect, Single width, Single height, UnityEngine.GUIStyle style) [0x00000] in <filename unknown>:0.

Hello, I seem to have a bug where the cameras (both docking and non-docking) show only the skybox and some static models. This occurs only when I have set the in-game resolution to less than the full desktop resolution, and have set the game to full screen. If I set the game to windowed and less than full desktop resolution, the cameras work normally. Also, if I have the game set to full desktop resolution and full screen, the cameras also work normally. This testing was conducted on KSP x86 on Linux. If you need further info or screenshots, I would be happy to oblige.