Starwaster

That's too bad. You should share your newfound knowledge with the other people in this thread who were complaining that it did not work for them. And what should I tell the next person who complains that it's not working for them? Should I tell them to contact Helix935 for support?

Density and pressure are not the same thing at all.

i think that the first time docking is initiated that something is not initializing correctly. I routinely immediately cancel and reinitiate. Try that. Just assume that it's not going to work. Second time always works for me but if you wait too long to cancel the first attempt, that makes it harder for the second attempt. It has to correct the first's errors.

Porkjet has stated that those are NOT intended to represent RCS ports on the Mk2 cockpit.

Send them to the kids table. Yeah, the thing with the Rendezvous component is that it seems to execute burns BEFORE it is time to execute them. (i.e. IMMEDIATELY instead of 2 minutes from now, or whenever the burn is scheduled). The workaround for that is to cancel the Rendezvous autopilot when it sets up the burn to match velocity and instead use Maneuver Planner to execute that burn. (or even use MP to set up and execute) Docking, havent had too many problems with it. Having a balanced RCS system helps A LOT. The MJ RCS balancer can help out if it's enabled but that's no excuse for not taking the time to balance your RCS. If you have multiple components that you plan on docking to form a complete vessel, good placement is on the average Center of Mass. (if you don't have the RCS balancing plugin, GET it. USE it. SHows you in the VAB how well your RCS will work for Center of Mass, Dry Center of Mass and Average Center of Mass. (average between full and dry)

Sorry but I still have no idea without logs. I'm not a psychic and I can't do remote readings.

Judging by the name he gave his craft, I have a feeling that he's referring to this bug here: http://forum.kerbalspaceprogram.com/threads/39512-0-25-Procedural-Fairings-3-10-payload-auto-struts-%28October-11%29?p=1551049&viewfull=1#post1551049

I'm not going to argue with you any more about your use of phys time warp, but when you get odd things happening to you when using it you have nobody to blame but yourself for persisting in using it. That's number one. Number two: Stop treating RSS Eve as Eve. What you can or can't do with stock Eve has nothing to do with what you can do here because this is Real Solar System and Eve is VENUS. Average pressure on its surface is 90 times that on Earth. You'd have to go a kilometer underwater to encounter such pressures on Earth. The altitudes you're dealing with in your descent when you come apart is the equivalent of flying on Earth or Stock Kerbin at 45-50 km with FAR except that you're travelling at orbital velocities. I don't know why you expect to do that safely in something as fragile as a space plane but you can't. Number three: Stock Physics. Sorry but I'm done here. I have to move on to other things (Deadly Reentry, Ioncross, Stock Drag Fix, in that order).

Rubisco, make sure you have this dll (the last beta download has a bug) https://www.dropbox.com/s/moge45bumutdcwj/DeadlyReentry.dll?dl=1 Fizwalker, are parts burning up? Or just coming apart? If the latter then that's FAR not DRE. FAR will punish you for abrupt supersonic maneuvers.

Thanks for that information! Very interesting. I've seen this reported once before (or something similar) but I need reliable repro instructions because so far I haven't been able to make it happen. I notice you mention driving, does it ever happen when NOT driving some kind of rover? Just sitting on the surface?

Just because you got away with it one place doesn't mean you can get away with it anywhere. Math errors make bad situations worse. The first time you ever do a physics time warp on a new KSP install it even warns you that there can be consequences. Is it really so surprising to you to actually see that in play? The more you time warp the worse the problem gets. Fewer and fewer data samples and updates occur causing math errors to creep in. Not only that but KSP's code mixes doubles and singles allowing for math errors even when not time warping. When you combine the two the problem gets worse. You can see it at play in anything that depends on measuring time delta (the amount of time between updates) including generators and solar panels losing power during time warp when they should be gaining. You can see it time warping in Deadly Reentry when a shield depletes in seconds when it should have lasted all the way down to landing That's also the reason why you aren't allowed to physics time warp faster than 4x.

I have no idea what you're trying to actually communicate there. Just in case it wasn't clear btw, 'they' happens to include me. In any case, the more I look at your video, the less likely it is that this is a problem with Real Solar System. You might not think that that fractional density of 0.001 is a problem, but that's about the equivalent of 45,000 altitude over Earth, and you're doing over Mach 25 in it. In a space plane. Maybe you could pull it off in a less sophisticated design, but nothing that you're going to take off in again. By the way, you do understand don't you that Eve is Venus in Real Solar System? Its atmospheric pressure is 90 times that of Earth's? That's why I say your 90 km altitude is the equivalent of 45km Earth. And doing a physical time warp isn't helping you either. Doing so causes math errors in everything that's going on in your reentry including FAR's calculations for application of force. I'm not at all surprised that you're breaking up there Edit: Also, if by some miracle you make it down to the planet, those Kerbals are never leaving that planet. Not in that plane.

You don't, because Module Manager would not cause your atmosphere to disappear. All Module Manager does is apply patches against your game files after they are loaded into memory. One of those patches could cause you trouble but that's not the same thing as Module Manager being the problem and you should not delete it. Instead of trying to fix this yourself you should submit log files and let an expert help you.

As far as engine parts having built in intakes, B9 has done exactly that on several of its radially attached engines for a long time now. FOr DRE shielding give the parts 0.25 reflection and no ablative. Angle the direction 45 degrees down. Except wings. Those should be omnidirectional

Everyone does. Engine tweaks scaling is disabled. (Edit: when using real fuels)

It would be a good thing for you to provide a save file with a single craft on approach to Eve. That would be the easiest way to try to reproduce your problem. (stock or B9 parts on the plane please) I have a setup that I can try that with but I don't have the time to put together a plane and launch it and send it to Eve. Edit: And regarding your other post, any density changes are coming primarily from FAR utilizing pressure and temperature, which is why I mentioned Eve's temperature curve below (Edit: Above! I meant above. Previously). It affects density. If there really is a bug in RSS it can ONLY be in the temperature or pressure curve. RSS doesn't have anything else that can affect density except those two things. FAR does everything else including actual density implementation and application of the forces that are destroying your plane. You might have been playing with FAR for a year and a half but I've contributed code and support to RSS for as long as it's been around and I know how it works internally.

Your descent speed isn't really relevant to what people are telling you. A Mach 25 reentry is a Mach 25 reentry no matter how fast your actual descent rate is. And it's not just a matter of being testy, you're coming in here seeking help because you don't know enough about what's happening and you're looking for people that do. So you need to be more cooperative with those people when they try to help you and follow their direction. Let's start with some log files. Your logs will tell us everything about your installation that we can't get from your video or from questioning you.

The wiki article has some good information on reentry heating which more or less agrees with other literature I've read on the subject. There is an absolute wealth of information on government servers, a lot of it declassified from the 50s and 60s. I can't give you links to those because I don't have them anymore, but maybe some day I can get around to putting up all the PDF files I've downloaded. (for Nathan if nothing else; he expressed an interest in them for working on Real Heat) Wiki link (directly to shock physics section) http://en.wikipedia.org/wiki/Atmospheric_entry#Shock_layer_gas_physics Keep in mind though that what DRE is using is extremely simplified as mentioned before. No stagnation, no real gas model. I did however assign different planets differing densities (in the form of differing gas constants) and that definitely does make some difference. Especially for Jool, though a real life reentry (Galileo) probably is a lot different. Edit: Comparison of Mars/Earth reentry Index of NASA information on supersonic flight, reentries, etc. Not that useful IMO... kinda dumbed down. Some FAA.gov stuff on reentry. Some useful information here but I dismissed it as not being relevant to DRE. (again, simplified)

Try replacing your DeadlyReentry.cfg file with this version: https://www.dropbox.com/s/dzyccxas59z2d7l/DeadlyReentry.cfg?dl=1 It adds entries that try to increase detection for shielding for those parts

The latest update removed Firespitter as a dependency for the landing gear. That's what I recall anyway and that's what the release notes say. Are you guys sure you have the very latest download? If so, try uploading logs (output_log.txt - player.log if MAC/OS or Linux). I'll take a look at the logs for you and see if I can spot anything unusual relating to the KSO gear (I'm not affiliated with KSO, but I do know my way around the log files)

Then don't use physics warp. I can't compensate for that in the code, especially when floats are mixed with doubles. Don't do it. Edit: A better explanation. When you speed up time like that, I'm dependent on the game telling me how much time passes between updates so that the code knows how much material needs to ablate from your shield and how much heat to apply to the parts. Fast forwarding results in lower precision. It leads to more math errors. Your 'phantom forces' are the result of accidentally enabling trim. That's what alt+D does. You can cancel trim with alr+x or use the beta which has a toolbar activated menu from which you can access debug settings. Settings are specific to each of the three difficulty settings. Give me the part name of the jeb 9000 from its part config file and I'll try to tweak some settings for it in the next DRE release.

It's not imaginary. As an object passes through the air at supersonic or hypersonic speeds, the air bunches up in front of it. Compression of any material raises the temperature. As said before, the resulting temperature increase in Kelvin is roughly equal to the object's velocity in meters per second. That's temperature. Think of temperature as the average amount of heat. Temperature is not quantity. Heat is quantity. Dense materials or media have more heat than less dense materials. So high up in the atmosphere at 7000 meters per second, the temperature is about equal to 7000 K. The denser the air, the more heat is transferred to the reentry vehicle. Blunt bodied objects like the backside of an Apollo capsule work to keep most of the shockwave from contacting the hull and also provide a lot of drag to slow the craft down. However, I've also seen it said that pointier vehicles would be better because most of the shockwave would pass by harmlessly. Maybe that's true too, but they don't provide enough drag to slow down an incoming capsule full of astronauts. There's a FAQ on the very first page that answers questions like this. It has a link to a file that provides shields designed for planets on that scale. (though I need to create a version of it that is not RO specific, it will work for you) That said, you might want to try the beta. Default DRE shields might deplete faster but will still protect better in the beta. They may deplete faster but will resist heating better. That part is still WIP, but when I test the beta with 10x Kerbol, I I explicitly do so without the RSS / RO class shields because one of the goals of the beta is to not be reliant on special configs. The logic is that materials that evaporate or sublimate do not heat up past the temperature of evaporation / sublimation until there is no more ablator left. (The same principle makes it possible to boil water in a paper cup: Paper can not reach its ignition point because it will not heat up past the boiling point of water unless massive amounts of heat are concentrated on it) Another word of advice, the more time you spend in the upper atmosphere, the more time you have to slow down. Some people might tell you to adopt a steeper reentry angle but that can result in high G forces killing your Kerbals.

I disagree. I think that err.... 'research' should be done. No doubt we can find some brave Kerbal 'volunteers' to help put this thing to rest?

Something that had KSPAPI in it. That's about the only thing that causes that.

It's probably a bug in Real Fuels. In fact there actually was a known issue similar to this where tanks would have different mass when launching than in the VAB. This bug is probably related to that one, only it happens when reverting.