Starwaster

Try turning MechJeb off on all parts except the one you really want to be in control. (there's a button in the context menu) The exception in onVesselWasModified isn't going to be responsible here and it happens exactly once whenever a ProceduralPart is on a vessel that is being loaded. (once for each PP). Apparently KSP hasn't initialized something yet when that event fires because it's firing before anything has updated. Next PP update will defer the event firing until the ... third ... FixedUpdate frame. (the event is necessary to force the FlightIntegrator to update the part's thermal graph, otherwise it will treat it as if it were never rescaled) Edit OH.... and if turning extra MJ units off doesn't help then go into Utilities and turn off intake management. It might have closed all your intakes and then throttled the engines down, assuming they were airbreathers.

Except that it's based on Atlas / Centaur instead of the newer guidance used by the shuttle and others.

Ignore Google and go there anyway

I forget about FSFuelSwitch but is it possible some of their fields might be set negative on occasion? For instance, in Real Fuels, a -1 baseMass for the tank module means that it uses the part.mass instead of calculating basemass + tank masses... maybe FSFS does something similar? Why not look at your ModuleManager.ConfigCache and see if it's got negative values for that or any of the other values you're operating on?

@KerbMav keyA[0,;] to target the first element of keyA... keyA[1,;] to target the second element. Usually it would be keyA[0] but your delimiter is a semicolon so it's keyA[0,;] (see the comma followed by semicolon? to signalize that a semicolon is the delimiter being used)

@JaviLL Just a thought... it might be that the propellants in the main RCS module aren't set up to allow crossfeed and most of the resources involved don't allow it. But in the engine configs (which also covers RCS) they are set up to allow it. (engine and RCS configs can override resource flow settings) I don't actually know that's what's happening mind you, I could be wrong. But it just seems like the sort of thing that would confuse the stock KSP code.

It doesn't glitch your solar panels. But maybe you have a Module Manager patch that is changing your solar panels. It's not going to be possible for anyone to help you though without a lot more information: detailed description of the problem, log files (uploaded to an appropriate site such as Dropbox) and maybe your ModuleManager.ConfigCache file.

Real Fuels lets the player control what resources are assigned to a 'tank' part. (tank can be a loose term; in this case it would be like a battery) The thing that determines what a given tank can hold is the TANK_DEFINITION. The patch in that pull request lets any tank that could have electric charge (basically adding batteries to the part) also add StoredCharge. As you note in the PR comments, by itself it seems to do nothing. The player could configure tank parts with StoredCharge but if, as you say, your mod / resource definition won't allow for StoredCharge to actually flow into the part then it's probably pretty useless. Nothing else in there adds your mods modules to the part. (the kinds of parts that this would affect in RF would be plane fuselages, service modules and electric propulsion tank parts (Xenon tanks that also contain batteries for ion engines) About the mass / utilization... that looks really screwy because the end result is that one StoredCharge would require a 'tank' mass (really battery mass) of 2.89 metric tons due to the math involved. Mass is the tank mass for one volume unit and utilization is how volume unit of the resource will fit in one tank volume unit... EC had a utilization of 1000 and mass of 0.00289 so... yeah, it's going to end up as 2.89 tons per volume unit of SC.... I am not familiar with your mod and what kind of power density your batteries (capacitors?) have so I could be wrong but that seems screwy to me.

I don't know that drag cubes actually affect whether a cargo bay is determined to have contained its contents but there's also the matter of the lookupRadius. The deployment bay has a lookupRadius of 1.75m. If Tweak Scale doesn't change that when the part is scaled up, then your engine has to fit within 1.75m or it's not contained. Even if Tweak Scale were to update the drag cubes, it would also have to modify lookupRadius

Yes but you told us not to pay attention to you, so why should we respect your wishes not to be paid attention to?

A better indicator of drag would be to enable physics aero debugging and right click the engine inside the bay. Do that without opening the bay or the data presented will not be reliable.

It doesn't matter if you crashed or not, you always have logs unless you explicitly disabled logging. Go back, visit the link he provided for you and read it. It will tell you how to find those logs.

No, it has to have an update for KSP 1.3.0 - that hasn't always necessarily been true of past KSP updates; sometimes a plugin would continue to function with new KSP updates, sometimes it would just need a recompile and sometimes it would need code changes. Usually, failure just meant the plugin wouldn't function. However, with KSP 1.3.0, if a plugin hasn't been recompiled and a part is present with a PartModule from the un-updated plugin then KSP crashes when it tries to compile that part. Personally I consider that a bug and I think Squad does too in that it should be able proceed without crashing though the plugin would still be non-functional. (could be wrong though, maybe it's not being considered a bug)

Just out of curiosity, probably nothing but have you tried with the motor disabled? Just thinking maybe there's some weird interaction between the brakes and motor...

You can easily add RCS transforms to those parts of yours and it's a good entry level way to learn how to use the Unity 3D editor. By default, RCS uses the Y axis unless useZAxis = true Then add them to the part with MODEL nodes. (adding MODEL nodes requires that the main mesh also be added via MODEL)

You know, (not to stray TOO far off topic...) but if Steve Jobs controlled all aspects of iPhone design and anything that he didn't personally like and would have taken steps to ensure maximal 'Steve-Compatibility'... what the hell did the insides of his ears look like? I mean, those Earbuds.... they don't fit in the ears of any known living humans. But they MUST have fit Steve's ears or they wouldn't have shipped. In fact, the entire damned iPhone project would have been held back if those damned earbuds didn't fit Steve's ears. Just.... just think about that. Let it sink in. If you own a pair, take a good look at those earbuds that will NEVER fit your ears and think to yourself... there was one SINGLE human on this planet that these earbuds once fit.

So @Nils277 is actually Steve Jobs now?

It's certainly 'possible' but to what end? Safety again? A safe velocity at one altitude would be dangerous at another. Chutes designed for Mars for example have to open at velocities much higher than they would typically be operated at here on Earth. but they not only can (because of the lesser atmospheric density) but have to because atmospheric braking is less effective over Mars (or Duna). Velocity as a trigger is probably the least desirable.

You'd need to use reflection to pull the grounded field out of KSPWheelBase...

Your craft should be able to translate (left/right/up/down) without any torquing at all. If translating results in torque then it's going to have to fire other thrusters to try to compensate. That compensation is probably going to interfere with its efforts to translate. RCS Balancer may help but it's better to have a well balanced craft to start with. Also: Docking AP speed limit: Best to leave it at default unless your balance is perfect. Lowering the speed limit may help with balance issues but the AP starts having problems if it is too low. (0.25 is a good lower limit; 0.125 is probably too low) Sarbian mentioned that the position and velocity could be a frame behind. That tends not to be a problem until the speed limit gets as low as ~0.1 - 0.125 m/s. (and the closer it is to the target, the slower it wants to go). (The swinging back and forth does sound like a balance issue. Test that by turning on RCS and pressing I/K/J/L - it should move laterally without turning at all. If it does then that's a balance issue. If it's only a little off balance then maybe MJ balancer can help like I said before)

Try decreasing springiness and increasing damping.

Make sure you have the right mod version for KSP. There is no update for KSP 1.3 if you require any help beyond that then logs logs logs

Two possible causes: The gimbal transform has to have its Z axis aligned with the thrust transform Z axis in order to have independent gimbal range limits on the X & Y axes. As I understand it (and I'm not 100% sure on this) gimbal transform orientation was not important on a per-axis basis in older versions of KSP as it seems to have been used primarily as a rotation point for the thrust transform and/or other engine parts. So if, for example, the X axis is the one aligned with the thrust transform then that means the Y axis is unaccessible The gimbal transform can't be the root or it won't function. There needs to be a base empty GameObject other than the one with the gimbalTransform or it won't work. I do not know why that is but I couldn't get the Procedural SRB gimbals working properly until I sandwiched the gimbal transform between the bell and another GameObject. I suspect that it's not possible to rotate a transform unless it has a parent object and the default orientation is Y = Up. So if that theory is correct (and experimentally it seems to be) then any rotations I make in the Unity editor don't get applied in the game unless there's a base parent transform. I have no idea why that would be the case as it always worked before. Or it's possible the theory is not correct and that there was another underlying cause preventing the gimbal from working until I gave it another empty GameObject as a parent. (or even another mesh) Clarification on #2, when I say 'not possible to rotate' I mean only in regards to naked transform rotations not surviving the export to the game. Edit: After hacking on PSRB some more today I'm not sure how relevant my experiences with it are to the gimbal issues on this mod. There's things going on with that mod that are unique to it and maybe not relevant after all.

Yeah I've tried it before, ended up with several different sized meshes that were a PITA to sort out. And then because I'd rather be dipped in bees than to use Blender, I had to export it so I could do the work with Softimage/XSI/Mod Tool

Unlikely without at least the files he worked with in Unity. Could maybe fix it there but it might take reworking of the original models, I don't know. I know of one of two things that can cause this as I'm facing a similar problem with Procedural SRB where I DO have access to the original files and have had some success, but with side effects that might result in me doing the thrustTransform thing after all