Starwaster

Thirteen times now...

@Gotmachine how about a pull request?

Believe it or not, the cause of that has always been there. It's just usually not noticeable because when the effects were at their most extreme it tended to obscure the problem. Render depth issue probably.

Delete all but the most recent ModuleManager copies and try again

It's not just particles, in fact I can probably fix the particle issue in DRE once I understand the new particle system. The stock reentry FX that KSP has aren't particles, it's creating new geometry from the part meshes and manipulating them. Not sure a mod can fix that at least not easily.

I'll use this opportunity to just leave these examples of 1.3 reentry and 1.4 reentry using the same OPT Space Plane vehicle... (that nasty looking plume is Deadly Reentry 'on fire' FX from the RCS parts which are burning) KSP 1.4 KSP 1.3

Yeah I'm thinking World Stabilizer might help with a lot of issues (ok one issue causing lots of problems), including my local abuses of the Bon Voyage mod...

@Nertea But also please fix problem X!

Please make your ModuleManager.ConfigCache file available to me for download (Dropbox preferably) And your output_log.txt file

Did you back away from the port before trying to dock? It is necessary if you want to re-dock after undocking. Default distance is 1 meter though it can be changed in the config.

What you can do is find the base normal discounting terrain and rotate the vessel to that. That will work for flattish terrain. Then fine tune it when it comes off rails to match it to slopes.

Here's a craft file to contribute to the cause. It's the same basic configuration as in the video using all stock parts. https://www.dropbox.com/s/j7or2tb33u874jx/Control Authority Tester.craft?dl=1 Don't try to dock it to anything though, not just yet. Just cheat it on up into orbit and put it through various attitude paces using SmartASS using all default Attitude Controller settings. Control it from its probe core first and pick an attitude (Prograde, Normal, Radial), Force Roll: 0. Once you are satisfied that it can adopt an attitude with a particular forced roll setting then switch control to one of its docking ports. Watch it thrash and roll and oscillate back and forth unable to reach its goal. If it can't do that then it can't dock no matter what you do to the docking AP. Fix the control issue first and the docking AP will be able to dock it. Whether that means calling it a pilot issue and tweaking PID settings or whether that means you decide that the attitude controller should be able to control it just fine and that it needs a code fix is up to you. But one of those has to happen in order to dock a craft of this configuration no matter what code changes are made to the docking AP.

There's lots of things Kerbals shouldn't be able to do, yet are. Such as surviving a 6 ton lander coming down on them when it retracts its landing gear.... Edit: Or destroy utterly demolish said lander by paragliding into it at top speed!

@Stormie Ok so I replicated your problem... I missed where you said it was the LARGE docking port so I didn't see this happen before. I guess I haven't used that port in awhile. And I know what's doing it but I don't really know why. KSP has had detection to make sure vehicles aren't buried in the ground when loading in. Sometimes it has't always done its job and 1.4.1 was supposed to have greatly improved that behavior. The only thing I can figure out is that for whatever reason KSP thinks that the part is loading in almost a kilometer underground so it is moving it UPWARDS by an amount it thinks will resolve the issue... [Untitled Space Craft]: ground contact! - error. Moving Vessel up 998.402m The thing is that KSP uses raycasting to detect where the vessel is in relation to the ground so I don't get how it thinks it is 1000m under the terrain. There must be something about that part's geometry that is confusing things but I don't understand what that could be. If I use the gravity hack in the cheat menu and set gravity to 0.01 then it floats back to the runway unharmed and I quicksave and then quickload and this time the part loads in without issue... Dunno why. I suggest downloading the following. It works with 1.4.1 (YMMV) and it does the same thing that KSP does which is move the vessel upwards, but it's a little more sane than KSP is (whose Sanity Check bounced) I tried that and the part loads in without teleporting up into the sky. Give it a try and see if it helps you.

Not enough information to go by, where's the logs? where's the ModuleManager.ConfigCache file? What KSP version? Did you try just stock KSP + ModuleManager + Procedural Parts? Can't do anything without information.

@StickyScissors Here's my so-called janky craft docked together. Have fun watching yours oscillate

If you get oscillations you have a control issue regardless of whether it worked in 1.2 You didn't have a control issue then You have one now and you need to get it under control.

Not a docking AP problem. It's a control problem. I know you don't want to believe that but it IS. That craft has several balance issues and your video screams control problems and it doesn't matter if you made it work before. @DerekL1963 is 100% right, you have a control reference point that is far off from your CoM but your thruster control scheme is arranged around that same CoM. The practical implications are that are: The attitude controller is going to try to roll around the docking port as a reference point but your thrusters are balanced for the craft CoM. So every attempt to roll is going to throw the ports out of alignment with each other. That's inevitable. Both the attempts to adjust roll and the attempts to compensate for the resulting alignment issue are using the same thrusters for each attempt and are likely using the same thrusters that are used for translation. (if you have thought of this latter point already and set up dedicated thrusters for translation then you should check them again as you will probably find that your settings for those parts have been changed due to MJ's 'Smart Rcs' setting) I set up a pair of craft similar to the ones in your video and was able to make it work by Turning on RCS lever arm compensation (press caps lock so that pitch/yaw/roll indicators turn blue) Because of the above it was necessary to change attitude control settings. I set Tf min and max to 0.01 and 90. Those are unusual settings that I wouldn't ordinarily suggest but that was the only way MJ was able to control things. Set the Derivative term to 6. (PID). Set the maximum relative angular velocity to 0.01% from the default of 0.15% - This past part is important because you want to limit the impact of your rotational burns. Look at your video, it's yawing and rolling far too violently. MJ's RCS balancer can help or it can hurt you here. For part of the approach I had to turn it off but to help it close the distance I had to turn it on. If you do get things lined up and stable and the docking craft actually approaching, it is still going to have trouble keeping the ports aligned and the docking AP is probably too strict about how far off it can be. The way it resolves this is by slowing your approach speed until the lateral port distance has been closed. I think it limits the approach to 10% of the lateral speed... I forget. But you have got to get that control issue in hand.

Grid fins are more for stability and control than for slowing anything down, (at least IRL).... maybe you just need to start burning earlier?

Looks nice though I have to question both the notion that these are going to significantly reduce drag as well as the notion that the stock part 'greatly increase(s) drag'. They are somewhat smaller than the stock 4 way RCS but close in size to the linear RCS part. I also notice that you scaled down the maximum_drag field but that is only used under very specific circumstances and never when drag cubes are in play for a part. Either a player would have to have their PhysicsGlobals drag model set to spherical or you would have to set the part's drag model to spherical or one of the other drag models that actually use maximum_drag for anything. (minimum_drag is no longer used as best as I can ascertain)

@Stormie I will look at your log when I get home

I have on occasion seen a piece of debris from just such a field gone whizzing by one of my craft, usually during final stages of its ascent. And by 'whizzing by' I mean close enough to be in visual range and with enough relative velocity that it could have damaged something. The odds are probably slightly better (though still low) than IRL since we telnd to launch more missions into the same orbital plane than in IRL, but I've never actually lost anything. But it's made me more mindful of where my final stages end up and I try to plan for everything to reenter. Unrelated to your question but still funny story about 'debris'. I once sent some Kerbals on a mission to Duna. Their propulsion stage was: NERV, large tank of propellant and a Sr Clamp-o-Tron. Once in orbit, I detached and sent the lander down to the surface. The command module was equipped with a docking port so I could reconnect to the propulsion stage and come home. Unfortunately, before that happened I went into settings and reduced the amount of debris that the game would allow to exist resulting in my propulsion stage being culled... It hadn't occurred to me that it qualified as debris.... So always put something on your stage that prevents that from happening. (back then that would have meant a probe core... these days even a relay antenna would suffice. And I think 1.4.1's new renaming rules allows you to change how parts get classified if undocked or separated?) Edit: Oh and I think there used to be such a mod... somewhere.... somewhen.... have to look into it. Do a search, see what you turn up. Search for Kessler and limit it to title only. Once they're close enough to be visually seen they're close enough to come off rails

I'm using it in 1.4.1 as is.... Yeah it probably has something to do with your 17,440 exceptions. Kopernicus has classes that won't load 16,284 instances of 'MissingFieldException: Field '.KSPParticleEmitter.pe' not found.' and I have no idea what mod that is from BDArmory throwing exceptions - and it seems something like 13 of those parts don't even compile FAR throwing exceptions trying to access colliders I'd start by uninstalling any recent mods you installed and trying again. A good deal of the errors are happening before you even finish loading the game btw.

LOGS

@bewing Maybe you're thinking about its ballistic coefficient because of the extra mass it adds to the craft but it is not physically possible for it to have less drag unless there's something seriously wrong with the game's aerodynamics.