Starwaster

Scales reaction wheel torqueing down to 10% of their stock values since reaction wheels are overpowered. It's a little brute force and I can't say with 100% certainty that I haven't limited something too far but the attachable wheels work ok and things that I want to be limited are limited (command pods...)

I agree with everything except this... I use the following patch and don't have a problem with flipping except when it's my fault (poor design) Also, @Quarkz not sure logs would help in this situation so not asking for any but I just noticed you saying a few posts back that you didn't have any because there weren't errors or crashing. Sorry but that is WRONG. You always have logs unless you explicitly disable logging. Remember that.

That's what + does +PART means clone that part Renaming it after is mandatory, otherwise you'd just have two parts with the same name and that causes problems

Steve Kerman... a Kerbal barely alive...

It should, yes. One thing I'd like to add to what @Voodoo8648, limiting acceleration to 30m/s is a good value for Kerbin if you have a high thrust rocket so you don't waste fuel. But, I notice you have solid boosters on your rocket. If those aren't gimballed (and if they are the stock boosters then they are not unless they've been patched to add gimbals) I foresee a problem where if you've limited your thrust to a given acceleration value, MJ2 very well might throttle all the way down to zero and then you will have no control authority. The way around that is to set a minimum throttle limit (Keep limited throttle over) that prevents other limiters from setting the throttle below the percentage that you set. Right now though, there's a bug that prevents keeps the minimum from kicking in when it's supposed to but there's a pull request in to fix that.

You can paypal.me/Starwaster if you like, I won't say no! Not necessary of course as these are all mods that I need to update if I want them for my own use

I'm not understanding what you mean. Can you be more detailed?

That sounds like the opposite of what he wants. Do you mean to start the burn ahead of time so that half occurs before the scheduled time and half after? (such as for long burns?) If so, it already does that.

If parts of the world extend past wherever the atmosphere ends, then yes.

Those changes are not required for either the stock SAS or MechJeb to see the changes that Dynamic Deflection makes. They see the changes just fine. And how much control does your changes exert over the authority limiter? I, the player, still needs to be able to use that slider. That's for me to use as the End User.

Correct, not without overriding the stock code.

No, you're stuck with showing restraint and not using MJ2 to control with until it gets back in comms range

Throttling does not work. Other commands such as attitude control do. I *think* that if auto-RCS is enabled that it can also turn on RCS but I'm not 100% sure on that. I think it should be changed such that MJ2 can throttle and do everything else while out of range or when occluded but only if those things were set up prior. In other words, if the craft is behind a planet, you can't set up a Maneuver Plan or use Smart ASS, etc but I haven't had the time to look into HOW to go about doing it. I think definitely we need better compatibility with the comms system so that MJ2 cant be used to outright bypass it (they can always enable limited control if that's what they want). And so that all features will work if they were set up before going out of comms. Maybe after finishing with everything else I'm involved with I can look at that.

If you want to, sure, go ahead. Probably won't get done otherwise. (I mean, I don't know enough spanish to do it)

There are TWO builds of 7.6.0 - one for KSP 1.2.2 and one for KSP 1.3.0 Just use the correct build for your version of KSP.

I have gone into the PP repository and merged some pull requests, except the ones for things that had been done already. One (1.3 compatibility changes) I'm holding off on so I can do a final 1.2.2 update. So probably sometime this week but after the final update for DRE. (which is still in pre-release status)

How persistent is that data? If not could it be made persistent? At least for the altitude? Assuming the altitude is a typical one for that rocket (which it probably should be but knowing players, who knows)

@Starman4308 Or if not the log at least the entire patch and not 'stuff' and 'other stuff'. I can actually see something wrong in what you posted but I have no idea if that's a typo because you typed it in or if it's really representative of the problem. If you're getting errors, syntactical mistakes are a likely cause but who can say what's wrong from pseudo code?

Your problems are linked. It doesn't enter your target orbit for you, you have to do that yourself. If you don't do that and the altitude entered is very different then the phase angle is going to be wrong. So you have to enter the orbit altitude manually. It doesn't have to be exact but it does have to be close enough to put you in the right area. You can even do it a little lower or a little higher and then do a Hohmann Transfer. One other thing that you need to be aware of is that even if you DO have the right orbit entered, you still might not end up where you want or need to be. That's normal because MJ2 doesn't know how your rocket is going to perform. So what you do is set all your launch parameters the way you want them and let MJ2 launch to rendezvous. Let it finalize the orbit. If the orbit is wrong, revert to launch and repeat the launch. This time, MJ2 knows how your rocket will perform because it just watched it in action! Now it will put you a lot closer to your rendezvous target. ????? Profit!

@Errol Some of the lines in the patches you included are wrong: #$mass should be #$/mass$

Looks like a typo. Here's the deal: Quite awhile back, some changes were made to a FAR method for getting air density and changes were then made to Real Chute 1.4.2 (not 1.4.3) so that it could continue to access that method. However, I then had a conversation with ferram4 in which he told me that we didn't really need to use that method anymore because stock KSP made it obsolete and that Real Chute should just stick to the stock method. So 1.4.3 removed that support. Bottom line though is that the FAR changes don't matter and should not affect your decision. You need the most recent RC update that is compatible with your version of KSP. If you're using KSP 1.2.2 (which you probably are if you're trying Realism Overhaul) then you should get Real Chute 1.4.3. If you're using KSP 1.3 then you should get Real Chute 1.4.4 (except that there has been no Realism Overhaul for KSP 1.3)

Your patch fails for those because they have no 'module = Part' in them. If it's not in their config node then it can't be targeted by Module Manager. You'll just have to target them each specifically.

At the same download page for DRE 7.6.0 is a plugin compiled for KSP 1.3.0 IT IS UNTESTED! Should work though. So just install all the 7.6.0 files to your KSP 1.3.0 installation then download file DeadlyReentry_7.6.0_for_KSP_1.3.0.zip, unzip it and install the plugin over the existing DeadlyReentry dll. https://github.com/Starwaster/DeadlyReentry/releases/tag/v7.6.0

Pre-Release Update for Deadly Reentry version 7.6.0 - The Ariel Edition! For KSP 1.2.2 https://github.com/Starwaster/DeadlyReentry/releases/tag/v7.6.0 Change Log Finalized implementation of Max Operational Temp system Implemented 'damage cubes' similar to drag cubes except that hull damage is now directional. If vehicle skin takes enough damage facing its velocity vector then hot reentry gasses can enter the ship and damage internals directly Internal damage handled separately and is not directionally based. Kerbal max temp rebalance finalized. Suits (skin) can withstand up to ~900 K but the Kerbal inside starts taking damage at 317 K EVA Kerbals now have a small amount of cooling. (500 watts but subject to rebalancing) Kerbals scream when on fire. Reinstituted menu setting for turning off crew g-force warning message. Fixed problem with calling part.Modules[*] (replaced with FindModuleImplementing)

Actually I shouldn't have referred to melting, it wouldn't so much melt as it probably would explode.. I'm not going to bump it up by too much... enough to ensure it is destroyed at an appropriate reentry speed and altitude.