Starwaster

There's a difference between what you're describing and an outright bug consistently causes more drag to the vessel than would otherwise happen The best place to cache that would probably be when the vessel goes on rails. There's a GameEvent for that.

Set the gimbalTransformName to thrustTransform. It won't visually gimbal anymore but gimballing will work, all axes. Including the ones currently broken. That's probably what needs to happen to the nuclear jet as well but I haven't even looked at that one.

Not without the source files...

No no no no no! Layered Animations is obsolete and is no longer necessary! The stock ModuleAnimateGeneric already has support for layers and I have discontinued Layered Animations. All references to ModuleLayeredAnimator can and should be safely replaced with ModuleAnimateGeneric. I can't guarantee that it will continue to be safe to use, now more than ever given that Parts with a dependent un-updated PartModule can crash KSP 1.3.0 Everyone should discontinue use of my animator and switch to the stock version and should not encourage others to use the old version. Seriously. Can crash KSP 1.3.0

That's unlikely because gimballing is handled by an entirely separate module, a stock module. ProceduralSRB has no direct interaction with it except to tell it what range the gimbal has (in EVERY direction). Changing the deflection won't stop gimbaling on any axis, it would only change the starting angle it gimbals from. There's no technical limitation imposed by that which prevents gimbaling. Edit: Not saying the two aren't linked, but it's more likely that a deliberate change was made in the model limiting its range of motion. Edit 2: ... After further deliberation, probably wasn't done purposefully at all. The original Unity source files are available and looking at them,what looks like the gimbal transform has its Z axis pointing to the side when it should be aligned with the thrust transform. Looking into that further...

It only gimballed properly on one axis. I forget if it was X or Z. Rotation would not work at all

@evileye.x Before I go any further with this I need to see your ModuleManager.ConfigCache (put it up for download somewhere such as Dropbox) - and low orbital velocity for you is what, about 6km/s? Re: Wildcard patching: No desire to do wild card patching. But thanks for the suggestion. @AlekM Do you have 'Large Spaceplanes' researched? (in stock this was Hypersonic Flight)

@evileye.x Those KScale64 patches are horribly outdated. Those are for pre KSP 1.0 heat shields don't do anything useful anymore. About the Mark1-2 pod not burning up without a heatshield.... if Kopernicus is installed then the Mark1-2 pod has minimal heat shielding added to it at 25% of what the bottom heat shield for that pod would have... however, the attributes for that shield assume a full sized RSS Earth environment with an orbital velocity over 7km/s and that might be overkill for Kerbin at that scale... The alternative would have been to only check for RSS itself (and probably 10xKerbol which has an equivalent LEO velocity) and then hope for the best for the other up-scaled Kopernicus mods. I'll have to think on this, maybe as I said, ONLY scale up for RSS and it'll just have to be the responsibility of other modders for other sized systems to get physics and heat shields right for themselves. Watch this space for more later; ZOo is on so ima in front of the TV now

@wb99999999 there is a known issue where thrust gets capped but it wouldn't affect you if you're using RO because you'd have RF installed... (different logic involved for each case) Provide a copy please of your ModuleManager.ConfigCache and a craft file where this happens keep the craft simple. Procedural SRB + stock and a description of how you put it together that resulted in the bug

Github is just a website; anyone can make an account there and click on things like 'issues' and 'new issue'. Non-programmers shouldn't find it intimidating. Github is useful for all kinds of projects where multiple people can come together and collaborate and track changes to their project over time. I am unaware of any bug where multiple SRBs affects thrust and burn time. I'll need more information about what you're experiencing and how to reproduce the problem. As far the gimbals go I am aware of the problem but can't trace it to any code or configuration issues. It seems like it's a problem in the model itself but I don't know what the solution is at this time.

Although not relevant to your current situation (which you seem to have under control) the third and fourth numbers are used ONLY to control the shape of the curve and can make transitions from one point to another more abrupt or more curvier. You only need to mess with them when creating a new curve. They're optional parameters but not using them can result in undesired behavior. Read more about them here: http://forum.kerbalspaceprogram.com/index.php?/topic/84201-info-ksp-floatcurves-and-you-the-magic-of-tangents/ Handy curve editor here: http://forum.kerbalspaceprogram.com/threads/83246

Sarbian removed it from the list because it isn't supported anymore. Parts of it are broken and cannot be repaired at this time.

@AlekM question: is it a career game? If so then those parts might just be incapable of surviving Reentry. If it's NOT career or the parts list a skin max temp of something in the 2000s in the editor or list a max operational skin temp that high then you might be too steep. You want a perigee of 60-100 about halfway around the planet from your landing point.

@felcasbecause it does what you tell it to. Even chutes used on spacecraft IRL work that way. They have a set of triggers and when those criteria are met they deploy. Apollo didn't have a 'safety check' it had a barometric trigger and when it reached a certain pressure the chutes deployed. They knew that it would already be at a safe speed when the altitude corresponding to that pressure was reached. That's how it is in real life and these are Real Chutes not KSP Chutes. The whole point of them is to bring a measure of reality to parachutes and that includes the ability and responsibility to properly design them them for the craft and expected environment.

Probably because some of them are shielding each other. A part doesn't have to BE shielded to provide shielding. It's not really very realistic but that's the price to be paid for this level of abstraction. Realistically, everything there is going to get a lot of heating.Not as much as the heat shield itself but still significant enough that IRL even parts behind the shield would need some protection themselves. Just not as much. And btw, DRE doesn't control that, just so you know: That's stock.

@makuclib That stack is way too long to hide behind a 0.625m shield. Frankly you're lucky that anything beyond the first part behind the shield gets protected at all. You need a bigger shield.

@evileye.x @felcas No, armed does not work like that. Armed means the chute will deploy when it reaches its deployment conditions: Pressure or altitude for predeploy (basically the chutes are reefed) and altitude for full deploy (disreefed). It doesn't check safe state. All such checks are only used to color the icon background. Basically, playing using arming makes real chute deployment work like stock chutes, except that you can't configure them not to deploy in unsafe situations. Otherwise you have to deploy yourself and if they don't meet deployment criteria (pressure/altitude) then they don't deploy and you still have to deploy them when they meet those criteria. Armed does that for you and just deploys when they are at the right pressure or altitude)

No, that's more complicated than it needs to be, why do you think you would have to have preset angles? It's an animation, animations have animation limiters that control how far they can go. That's handled by the player in the context menu in the editor. All that's really needed is the animation itself. It's no wonder you have reservations about what I'm suggesting but it's really not that complicated at all.

First you're binding that animation to an action group. You'd use the animation limiter when building it in the VAB/SPH to limit its range to a desired preset. In flight you would toggle that animation if you want to move it forward and control the throttle as necessary to hover it or slow its descent as needed. Don't forget too that you can trim the controls, which I think a lot of players forget they can do.

using or not using MJ has nothing to do with tilting the entire craft is good or bad. If you're very close to the ground (as in landing????) then why would you want to be rotating your entire craft willy nilly? If you're landing a plane, or operating a VTOL close to the ground do you rotate the entire thing? I bet you don't. You want it straight and level.

You don't need three controls, mainly it's just going to be SAS for attitude control and throttle to maintain altitude. Or, autopilot. There's a number of options there. MJ2 of course, which can throttle individual engines and I use that regularly with my landing system that I use for both Lynx and KPBS to manage CoM shifts. In the case of the animated swivel that I propose (not the same as gimbals), differential throttle combined with MJ2's 'translatron' would easily allow for both attitude and altitude control. For those not wanting to use MJ, there's another mod that does the same thing which name escapes me. (some avionics throttle plugin)

I meant an animation that that would would animate part of the engine to change from pointing down to pointing back, or maybe somewhere in between. If set up properly, the thrust transforms would swivel with it. Straight back would allow the Lynx to transition to flying but if it were to point 45 degrees pointing down and back then its thrust would be split 50/50 down and back. A player could accomplish that by using the animation limiter, assuming that the animation were set up to swivel a full 90 degrees. Skillful application of the throttle or use of certain mods would allow the Lynx to hover in either mode, except that angled backwards would also propel it forwards. Think about the Harrier jet and how its engine nozzles can swivel. @Sebra says to just rotate the entire craft and that's a viable option. That's how the lunar landers would have had to change their landing sites mid descent, but it's also an easy way to lose control and wreck your Lynx. What I'm suggesting would allow it to remain level while moving about.

No, I meant swivelled to be pointing backwards. Although... maybe being gimballed would be good enough. They don't have to be fully backwards, even partially would allow enough tilt for forwards/backwards thrust and gimbals do that and are responsive to controls...

I don't use that mod and don't know what it patches so I can't say if it's sufficient or not. Of greater importance is how it adjusts stock convection heating because that's not something DRE touches anymore. There is a maximum temperature rating (ridiculousMaxTemp = 1523.15) that every part has its maxTemp adjusted to unless the part is set up to override that limit. And by default, parts take damage if their temperature reaches 85% of that value. (95% for engines). 1523.15 is a legacy value which looks like it was based on the melting point of steel but it's hard to say for sure. It's actually a very generous value IMO as aluminum is going to be more common as a construction material. (the shuttle's aluminum airframe could not be allowed to meet or exceed about ~450 Kelvin as it would begin to fail. That's why DRE adjusts space planes internal temperature limit to 453.15)

Taking your first question as literally as possible: You would have to install the plugin without any of the configuration files. Mostly those balance max temps of various parts. You would also have to add ModuleAeroReentry to every single part with the following parameters: leaveTemp = true, maxOperationalTemp = (that part's maxTemp), skinMaxOperationalTemp = (that part's skinMaxTemp). That would prevent the plugin from adjusting any max temps and prevent parts from being damaged when they overheat. They would instead just explode as in stock. DRE's g force damage system damages parts over time if they are over their gforce tolerance threshold, which is semi-random based on the part's crashTolerance. Stock's is a static threshold of 40. (actually it's configurable on a per part basis but to my knowledge, nothing changes it from the default of 40). If something is over its stock threshold then there is a random chance of destruction each frame. (in the future, DRE's will be dynamically adjusted such that very small parts have greater survivability and more massive parts lowered survivability). DRE's system can't be turned off but if you go into the DRE menu you can change gToleranceMult to something outrageously high which would change each part's gforce tolerance to something really high. DRE has its own system for Kerbal gforce tolerance and is too complex to address here. (it tracks Kerbal gforce accumulation over time if over a particular threshold and if the accumulated forces exceed another threshold then Kerbals can die randomly). My experience has been that the current settings will result in stock LOC before death. If they recover consciousness then death is not typically going to be a concern. Making changes to DRE's gforce death levels is something I use a spreadsheet if I'm going to make significant changes. I did that exactly once for Realism Overhaul to ensure that experienced gforces would be survivable at levels a human being could survive at levels that human beings could survive at IRL. IRL, humans can survive much higher levels than DRE's settings for stock because we're going for a gamier experience than RO players would expect) (TL;DR, I feel that the current stock DRE settings already sensibly lead to LOC followed by death, but if adjustments are required, a spreadsheet would be needed to make reasonable changes)