• Content count

  • Joined

  • Last visited

Community Reputation

404 Excellent


About Boris-Barboris

  • Rank
    I'll be right happy to

Profile Information

  • Location Russia

Recent Profile Visitors

8469 profile views
  1. [1.2.2-1.3.1] AtmosphereAutopilot 1.5.10 [looking for maintainer]

    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.
  2. [1.2.2-1.3.1] AtmosphereAutopilot 1.5.10 [looking for maintainer]

    @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.
  3. [1.2.2-1.3.1] AtmosphereAutopilot 1.5.10 [looking for maintainer]

    I'd say it very well is.
  4. [1.2.2-1.3.1] AtmosphereAutopilot 1.5.10 [looking for maintainer]

    @Phelan I guess AA's insides are unfit for thrust-based lift. Try Pilot Assistant.
  5. [1.2.2-1.3.1] AtmosphereAutopilot 1.5.10 [looking for maintainer]

    @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.
  6. [1.2.2-1.3.1] AtmosphereAutopilot 1.5.10 [looking for maintainer]

    Ok, show me the pic of the plane and in-flight picture while oscillating with FlightModel, Pitch_ang_vel and AoA controller windows open.
  7. [1.2.2-1.3.1] AtmosphereAutopilot 1.5.10 [looking for maintainer]

    @Phelan Does it wobble with moderation completely off (O hotkey)?
  8. 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?
  9. 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.
  10. 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.
  11. And what information about the craft exactly does the cone give you?
  12. 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?
  13. 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.
  14. Correct me if I'm wrong, but I don't remember anything like that in the API. What do you call "gimballed force extent" of CoT. What is the exact amount of "extent" and how is it calculated. And, finally, what meaning and practical use do you prescribe to it? Keep configurations like ... ... in mind.
  15. This one looks especially hard to design, not to mention implement.