Boris-Barboris

^^ and, btw, level flight AoA is accurate only for statically neutral crafts, for stable crafts it will always be a bit larger.

Things work well when someone made an effort to make them work well. Noone has done that for the combination of mods you use, on hardware you use, on KSP version you use. Such is the drawback of playing a modded game. I can only advise careful, manual management of your mod set and self-restraint. CKAN is a dangerous ally. Less mods = less things to break. No autoupdates - no surprises. There is a notable portion of players that still play pre-1.2.0 KSP, because they value stability of their experience more than new features.

It's more convenient to use new blank save with no vessels at all. If the lag is only in old saves and it doesn't appear in blank save .... I'm afraid there's no trivial way to search.

Fast way is to order mods in some (maybe alphabetic) order and use binary search: you remove half of the list and load the game (some test sandbox save with test ship and stock parts set up) and look. If lag is gone, return the removed half and remove the one on wich you have no lag. Recursively split the laggy half in two until you have found the offending mod or mod bundle.

Looks competitive. Good. upd: Hhnnnnggg

@Citizen247 Idk. Maybe bug in stock KSP and vessel landedOrSplashed flag is not reset by the game. Try with this dll to check this (but try to enable AA right after liftoff, not on the ground): https://www.dropbox.com/s/fzmrgz9k7o4cc10/AtmosphereAutopilot.dll?dl=0

Part's center of mass is set by default to 0,0,0 (wich is overridable via cfg iirc). Physics engine does not treat the part as a point mass. No. https://docs.unity3d.com/ScriptReference/Rigidbody-inertiaTensor.html

Not true in the slightest. Each part with a rigid body (so every one but the smallest utility ones) has it's own inertia tensor.

I'm afraid you got it reversed. Net force translates. Net torque rotates. In PhysX\Unity torque does not need a force to exist. I don't understand you, what do fuel tanks CoMs have to do with the topic?

PhysX allows to apply torque directly. Without applying any forces. Whatever you apply it to, it will simply rotate, no matter how complex, without translation side effects. Unless of course it's so big that PhysX solver fails to conserve momentum. you don't need forces at all for OP's case.

Since the actual control problem is quite complex, and it's solution does not (I assume, since it's you who is designing crafts) increase the gameplay value of your game, you can just abstract it away by one net torque to some big part of your craft. The control problem can be solved. Just assume that is it solved and already implemented in all your crafts by the lore, and just tune the net torque value for your likings\balancing. A lot of performance problems of KSP could be partially mitigated by such simplifications. IMHO, you want to solve a problem you don't need to solve.

Just a couple of tips that may or may not help: Every game object in unity has a transform. Transform is probably (Unity is not open sourced) a tuple of parent transform, local translation vector, local scaling vector and local rotation quaternion. Cached global (wich take parent transform in mind) translation\scaling\rotation are usually maintained under the hood. Essentially, transform gives each object it's own euclidean space (consisting of origin and three axels), and each transform describes, how to get from global, universal unity euclidean space to this game object's space, and vice versa. Now imagine a KSP aircraft. It has cockpit. Cockpit is a "control from here" part, it is a game object, it has it's own space, it has transform. KSP has these conventions: "right" unity vector of cockpit's transform is an X axel of cockpit's euclidean space. It's usually directed towards your right hand\wing. "up" is Y axel, it's usually the direction the plane\rocket is flying. When simple rocket is just spawned from VAB, it's command pod's "up" vector is directed towards zenith. "forward" is Z axel, it's usually directed towards plane's belly. Keep in mind Unity uses left-handed coordinate systems. Now, if you take vector (1, 0, 0) in cockpit's space, wich corresponds to the direction of the right wing, and apply cockpit transform's rotation to it (by multiplying it on rotation quaternion), you will get the direction the right wing is facing in global unity reference frame (in KSP this frame is usually non-moving relative to closest's planet surface, and planetarium axis-aligned, iirc). Now, there's a little gotcha in multiplication order in Unity, I'm sure sarbian will not mind this private message disclosure:

No, not really. Reset would behave just the same: spasms are normal when first starting AA on recently-spawned vessel. This will probably work, but it's easier to just try instead of guessing. My advice would be to make X-1 stable enough for it to fly OK for 5-10 of seconds without any control aid, and undocking while controlling X-1, so you don't have to manually switch vessels.

@awang 1). Yes, big airframe changes break the model and usually should result in a couple of seconds of spasms. 2). AA only controls the vessels on wich you manually pressed master switch. If you're connected and flying under AA, I don't think it's possible to make AA actually be activated on both crafts right after separation. It's either B-29 under AA, or X-1 - depends on wich one owned the root part, or, maybe, the owner of "Control from here" part.

I'd say it very well is.

@Phelan I guess AA's insides are unfit for thrust-based lift. Try Pilot Assistant.

@Phelan 1. Try switching max AoA inside pitch ang vel controller back to 15-20. Guys, AA will fail on small values, 4-5 is reasonable minimum for very capritious rockets. Anything flying should have 15+ in my opinion. 2. reducing cubic_Kp on AoA controller may tame it down. 3. Strength_mult of Cruse flight controller in advanced options can be reduced, but i think the first point is the most important.

Ok, show me the pic of the plane and in-flight picture while oscillating with FlightModel, Pitch_ang_vel and AoA controller windows open.

@Phelan Does it wobble with moderation completely off (O hotkey)?

Exactly. If you say "I want X, would be cool", I skip by. If you say "it allows me to do Y" and I clearly see that X does not give Y, I may appear, especially if it's close to my area of ksp-expertise. I considered it wasted, if the idea "X gives Y" was flawed in the first place. If he thinks "I'll do X, X is cool", i wouldn't consider it wasted. Yes, indeed, covered pretty well. Why do you ask?

I wouldn't even appear in this thread, if that was the exact thing proposed. The idea being discussed, however, is adding features of CoT on premise of giving additional information: " to help plan for controllability due to shifts in mass". Modder's time is as precious, if not more. I think you've more than made it obvious you don't support discussion on the forum, so perhaps you should leave it to those who do.

They show wich side the control surface is deflected, and help debug detect broken drag cubes. Besides debugging mods, they are useless in my book. Why would you spend development time to give the player fundamentally flawed information? You have 30 engines with different gimbals, placed in different parts of your craft. What do you show at CoT besides CoT? Play of the engines is explicitly stated in numerical form in their description. Visual cone representation is more of a tutorial value then. How do you derive maximum CoM shift from CoT. And from CoT with cones? Data it is, but nothing more, just bytes obtained from some algorithm wich in itself makes little sense. It needs to be something else in order to become useful.

And what information about the craft exactly does the cone give you?

Indeed, but then you would look at cones. But what value do those cones hold? How do they justify the time spent on their development?

Calculations, hidden behind CoM, CoL and CoT are identical in KSP. CoM: sum of products of position vectors of parts and their masses, divided by total mass of the craft. If you replace all individual gravity forces acting on the craft with one big force going through CoM, you will observe the equivalent behaviour of the vessel as a mechanical system. Linear and angular acceleration will be the same. CoM can actually be though as if it was the point gravity acts through. The same logic is than applied to CoL and CoT. With a big but. Abovementioned equivalence statement can be supported by short derivation from physical laws. Not so much for CoL and CoT. The reason behind it is that gravity is a constant force field. All individual forces acting on the parts are parallel (and this is why I drew that picture in a previous post, gimbelled thrust vectors will not uphold this restriction). As long as you keep all the forces parallel, you can repeat the derivation. Well, most designs have multiple engines, don't they? CoT is a pair of position and direction. For both position and direction the abovementioned algorithm (for CoM) is applied: instead of mass engine thrust is used. For position of CoT engine position is part of the product. Thrust direction is used in product for CoT direction. Now here's the deal: it's just a pair of position and direction. And that's all it is. Generally, it has no physical significance whatsoever. It has no use, no purpose, it does not describe anything, unless all your engines are thrusting in precisely one direction (restriction is actually not that strict for forces that are applied to a plain surface, but I lost the A4 sheets containing a more precise derivation and don't really feel like repeating it). And event then - what did you get? An edge CoT for full pitch down gimbal of your engine? Why would you want that? You can't do anything with that anyways - you are not accounting for aerodynamics, so you still don't know anything about your rocket's ascent. To conclude: no magical point or line are capable of describing complex dynamics of a craft. You want to know how it will behave without trial and error: simulate using game's laws, look at the graphs of kinematic\dynamic parameters. And guess what simulation is - a simplified, time-saving trial, game withing a game.