[1.9-1.10] Throttle Controlled Avionics

[RedParadize]

 

6 hours ago, allista said:

 

@RedParadize, I'm not sure I understand what exactly you mean, saying that many "advanced features" are enabled by default. The only things that are -- VTOL Assist and Flight Stabilizer -- for obvious reasons. And I'm not sure how many users would appreciate these be off by default.

User still have to go into advanced feature to find these two, and what they do is not obvious. There is feature that automaticly turn on or off under specific circonstance, and user will only learn it on the spot. Its quite surprising to see your landing gear retract on its own immediately after opening it. I remember that I got surprise like that many times. I wish I could give you more details but I uninstalled TCA some time ago.

I don't want to be hard here, its simply that right now we have a 3 inch thick swiss knife and when we pull the screw driver there is 5 other tools that come with it. And:

Spoiler

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.

                                                                                                                             Antoine de Saint-Exupery

I honnestly think that packaging the interface into separate feature box would be a huge improvement. And I hope you don't take it too hard, I am sure the many of the stuff you implemented in TCA 3 would quickly become a must have.

[allista]

10 hours ago, Morse said:

Well, as a very casual TCA user I can suggest one big problem: TCA2 was a pilot assist, TCA3 is a full autopilot. A whole paradigm shift denoted by just incrementing the major version. I assume that lots of frustration comes from people expecting one thing, and getting something completely different. And yet, while it is different, it looks the same, at least at first glance. Add to this the complexity and GUI, which is... not the best, and you'll get your people just wanting to get TCA2 back.

The key thing here is: TCA2 was. The best anyone can do about it is to fork it at the turning point and develop separately. I however do not agree with the contradistinction of "pilot assist" and "full autopilot"; all TCA3 functions are built atop the base functionality of TCA2 which is unchanged except for the fact that TCA3 can simultaneously work on several ships, while with TCA2 that was impossible. But that's all the difference that is. Everything else is just addition, not replacement.

[allista]

6 hours ago, AccidentalDisassembly said:

I guess my point is that it seems like the goal here should be (mostly) to simulate the effect of having an autopilot, not the intricacies of the system itself.

Are you bloody kidding me?! D'You really think this is some kind of simulation? Do you realize how complex and intricate the physics model in KSP is? How hard it is to squeeze an efficient algorithm in a Unity's fixed update, let alone to find one in some paper on the arXiv and adapt it? You imply I deliberately make the controls so complex that, oh boy, several people of some five thousand users come and complain they cannot handle a control panel with two dozens of buttons. Well then, have a look at TCA config files, see how much is under the hood and hidden from a user as to not frighten the poor sod.

Better yet, don't look anywhere, just write me a good working interface that will satisfy not these particular five good men/women/children, but every user. Can't write -- draw it in an image editor, whatever. 

As for the primary aim of TCA, it's as with any other mod: one makes a mod to alleviate one's own problems, having the fun of solving some mathematical and programming challenges in the process. One's glad if the result is helping someone else, but if one starts to perceive a mod as a work, bad things will happen. Because if you start to do things for someone else, you start to want something in return.

Dixi.

Edited September 2, 2016 by allista

[Morse]

13 minutes ago, allista said:

all TCA3 functions are built atop the base functionality of TCA2 which is unchanged

Well, that's when we get to the UI. You know the first rule of the UI design? If you need to explain it, it's bad. TCA main window has dozens of buttons, but only one of them is immediately clear to me: "enable". All the others I have to guess. "PG" "RG" and all the others? Not a slightest clue. "Engine profiles"? what is that? "Macro"? Are you kidding me? Do you know what a "young programmer disease" is? When a programmer starts adding features not because they are needed, but because he can. And on top of that you have the "advanced" button just mocking at me. Saying to my face "that? that's kid's stuff. How retarded are you not getting all that from the first glance. Just wait until you get to the advanced excrements!"

The autopilot modules can be guessed, but only just. What's the difference between "go to" and "jump to"? Between "level" and "cruise"? Between "anchor" and "hover"? Your UI follows the logic of the modules hierarchy, and not the user's task. When I press some button, I don't give two craps which class will do the task, but I really want to know what will happen to the craft. I enable the TCA and the control gets immediately stolen from me. The craft starts doing some weird maneuvers and I have no idea how to switch it off. That should be the basic: the button saying "do you want to fly yourself or do you want me to take over". And the button that defines whether autopilot should go straight to the waypoint, or doing the barrel rolls along the way - that should be in advanced.

So my advice is: list all the tasks that the average TCA user is expected to do. It is important to list those task in user's terms. User doesn't "level", "hover" or "cruise". He has a goal in head, like "reach the destination" or "rendezvous with someone" or "intercept". It's you who should know which module is the best in solving various tasks, not him. After you get the list, you can sort it by complexity. After that, pick 2-3 first tasks, and call them "basic": your "basic" GUI should solve only these tasks. More than 5 buttons, and people will start getting confused. Look at how I did it in my... hm... version: http://imgur.com/a/nliCP Also notice how I changed the "TCA role" into something easy to understand.

I understand it was the hard work to implement all that stuff. But you know what the hardest part is? To hide all that from the user. It's a pity user will never know how complex are the algorithms he is actually using when he presses the button "make me happy" (do you know this joke?). But users don't like complex.

[allista]

52 minutes ago, Morse said:

Well, that's when we get to the UI. You know the first rule of the UI design? If you need to explain it, it's bad. TCA main window has dozens of buttons, but only one of them is immediately clear to me: "enable". All the others I have to guess. "PG" "RG" and all the others? Not a slightest clue. "Engine profiles"? what is that? "Macro"? Are you kidding me? Do you know what a "young programmer disease" is? When a programmer starts adding features not because they are needed, but because he can. And on top of that you have the "advanced" button just mocking at me. Saying to my face "that? that's kid's stuff. How retarded are you not getting all that from the first glance. Just wait until you get to the advanced excrements!"

The autopilot modules can be guessed, but only just. What's the difference between "go to" and "jump to"? Between "level" and "cruise"? Between "anchor" and "hover"? Your UI follows the logic of the modules hierarchy, and not the user's task. When I press some button, I don't give two craps which class will do the task, but I really want to know what will happen to the craft. I enable the TCA and the control gets immediately stolen from me. The craft starts doing some weird maneuvers and I have no idea how to switch it off. That should be the basic: the button saying "do you want to fly yourself or do you want me to take over". And the button that defines whether autopilot should go straight to the waypoint, or doing the barrel rolls along the way - that should be in advanced.

So my advice is: list all the tasks that the average TCA user is expected to do. It is important to list those task in user's terms. User doesn't "level", "hover" or "cruise". He has a goal in head, like "reach the destination" or "rendezvous with someone" or "intercept". It's you who should know which module is the best in solving various tasks, not him. After you get the list, you can sort it by complexity. After that, pick 2-3 first tasks, and call them "basic": your "basic" GUI should solve only these tasks. More than 5 buttons, and people will start getting confused. Look at how I did it in my... hm... version: http://imgur.com/a/nliCP Also notice how I changed the "TCA role" into something easy to understand.Utils

I understand it was the hard work to implement all that stuff. But you know what the hardest part is? To hide all that from the user. It's a pity user will never know how complex are the algorithms he is actually using when he presses the button "make me happy" (do you know this joke?). But users don't like complex.

Have you ever saw a helicopter control panel? If you're trying to fly a rocket, or a VTOL, or a plane, you're not a "user", you're a pilot. You have to learn what prograde is, you have to read the manual to learn about engine configs and autopilots. And if you don't like the complex play tetris, for crying out loud!

I don't care what a user has in its head if it's not the brains which can think and learn. I make the mod for myself and other people who are nerdy enough to play a game that demands some knowledge of physics and engineering, not for someone who wants a "make me happy" button (no, unfortunately, I don't know the joke). I don't sell it.

Your interface is good. For a mod that performs a single task for a single situation. Go back to the first 5-10 pages of the thread and see how many would complain because this would not accommodate their designs and needs.

I do not say that the current interface is good; it's just the best I can produce having limited amount of time and being focused on functionality. And in my experience it's good enough to do everything that TCA does more or less easily.

[Morse]

1 minute ago, allista said:

I don't care what a user has in its head if it's not the brains which can think and learn. I make the mod for myself and other people who are nerdy enough to play a game that demands some knowledge of physics and engineering, not for someone who wants a "make me happy" button

Perfectly legitimate position. But then you'll have to accept that people won't like it. Let me remind you how it all started:

Quote

To be honest, even after all the discussion I fail to see the problem.

Well, now you know what the problem is

12 minutes ago, allista said:

Go back to the first 5-10 pages of the thread and see how many would complain because this would not accommodate their designs and needs.

Users usually don't know what they need, until they see it. Who knows, maybe the very function that'll make me happy is hidden behind the "rV+" button, I'll never know, because I have no idea what it does.

The main purpose of the game - is to be fun (that's what differentiate the game from a helicopter). So you should ask yourself: does your mode increase the amount of fun? Does it make the performance of tasks easier? Maybe it does for the complex tasks, but for the easy tasks it absolutely does not. Again, let me quote you:

3 hours ago, allista said:

all TCA3 functions are built atop the base functionality of TCA2 which is unchanged

Technically, you're right, they are there. But in practice, if I don't know how to access them - they are inaccessible. And if to access them is more complicated than to rewrite the TCA2... well...

And don't get me wrong, I'm not trying to make you rewrite the GUI or force my opinion on you. It's your mod. I'm just trying to answer your question "why people want TCA2 instead of TCA3 which is superior in every way", because I think this is the answer. Well, at least for me it is

BTW, the joke goes like this:

two programmers are arguing about the best GUI design. First programmer says: the perfect gui is just an empty window with one button "make me happy". Second programmer argues: no, the perfect gui is an empty window with no buttons at all, and just the text saying "you are already happy". http://bash.im/quote/52960

[Denko666]

oy, what a can of worms..... 

Mods are not commercial products, they are volunteer work. So don't go expecting After Sale Service. I agree TCA3 is complex, TCA2 was also complex to the untrained eye too... so really, where usage is concerned: RTFM. As for the interface, user-friendliness is an illusion, what works for one won't satisfy another. That said, there are certain design paradigms that in general will make usage of controls easier. IF Allista feels like reworking the UI, i'd say we chip in where we can with code or coin; do you have a Patreon account Allista?

I, for one, am in awe of what this mod does. Especially considering the code and math involved.

Do consider that no-one forces anyone to use this mod, if it's too complex or doesn't work as you expected: don't use it. Maybe Vertical Velocity Control is more to your liking. And also do consider perhaps the most obvious solution of all: if you think it can be done better: do it. It's all open source. Don't know how to? Learn it! 

 

[Morse]

3 minutes ago, Denko666 said:

And also do consider perhaps the most obvious solution of all: if you think it can be done better: do it.

Well, I actually kinda did

Good UI is not an illusion, and bad UI is definitely not an illusion. KSP mod is not a commercial product, yes, but if you're planning to become a professional programmer somewhere down the line, it's for your own good to start learning right away. I'm just trying to help, that's all. If my help is not needed, just say the word, I'll be off this thread faster than a speeding bullet

[Denko666]

3 minutes ago, Morse said:

Well, I actually kinda did

Good UI is not an illusion, and bad UI is definitely not an illusion. KSP mod is not a commercial product, yes, but if you're planning to become a professional programmer somewhere down the line, it's for your own good to start learning right away. I'm just trying to help, that's all. If my help is not needed, just say the word, I'll be off this thread faster than a speeding bullet

Don't take my post too personal Morse, i was addressing the complainers to TCA3 in general. 

 

[AccidentalDisassembly]

14 hours ago, allista said:

Are you bloody kidding me?! D'You really think this is some kind of simulation?  Do you realize how complex and intricate the physics model in KSP is?

I'm not sure what else we could be talking about here, considering we're talking about a computer game, and I think that's the definition of a simulation.

Quote

Do you realize how complex and intricate the physics model in KSP is? How hard it is to squeeze an efficient algorithm in a Unity's fixed update, let alone to find one in some paper on the arXiv and adapt it? You imply I deliberately make the controls so complex that, oh boy, several people of some five thousand users come and complain they cannot handle a control panel with two dozens of buttons. Well then, have a look at TCA config files, see how much is under the hood and hidden from a user as to not frighten the poor sod.

No, that's not at all what I said. What I implied is that you may have a different version of fun from other people playing the game. May. You said you didn't see what the problem is (why others might not see the mod in the same way you do), and I am suggesting that it's possible that that is what the problem is. Or not. I'm just going off of some posts. I also did not say that you deliberately complicate anything, just suggested that you might not be looking at the "issues" (whatever their magnitude) in the same way as others using the mod.

Quote

I don't care what a user has in its head if it's not the brains which can think and learn. I make the mod for myself and other people who are nerdy enough to play a game that demands some knowledge of physics and engineering, not for someone who wants a "make me happy" button (no, unfortunately, I don't know the joke). I don't sell it.

Well, that's fine. Do what you want. I didn't ask me for a "make me happy" button, I just tried to explain some principles from my perspective.

Quote

Have you ever saw a helicopter control panel? If you're trying to fly a rocket, or a VTOL, or a plane, you're not a "user", you're a pilot. You have to learn what prograde is, you have to read the manual to learn about engine configs and autopilots. And if you don't like the complex play tetris, for crying out loud!

Yes, and I've seen airplane control panels. I've even used simple ones myself, in real life! And yet these are not real planes or real VTOLs, and their users are not pilots. They're playing a computer game. Yes, it requires some learning. The question is how much, and what kind. If you decide that the answers to those question are "a lot" and "technical", which you are perfectly entitled to do, because you are doing this for free, and if people want something different they can do it themselves, etc. etc. - there is absolutely no problem with that, but, again: it will explain people's reaction.

[allista]

1 hour ago, AccidentalDisassembly said:

I'm not sure what else we could be talking about here, considering we're talking about a computer game, and I think that's the definition of a simulation.

This particular computer game is indeed a simulation. But since it's a good simulation, the engine balancing and autopilot algorithms are not -- they're the real thing. I can more or less easily transfer them to, say, a real life multicopter and it will fly. That's what I mean saying that this mod is not a simulation of an autopilot. After all, autopilot is a program 

Quote

No, that's not at all what I said. What I implied is that you may have a different version of fun from other people playing the game. May. You said you didn't see what the problem is (why others might not see the mod in the same way you do), and I am suggesting that it's possible that that is what the problem is. Or not. I'm just going off of some posts. I also did not say that you deliberately complicate anything, just suggested that you might not be looking at the "issues" (whatever their magnitude) in the same way as others using the mod.

Yea, right, sorry. I myself got too emotional with this. Fortunately, @Morse managed to talk some sense into me 

[allista]

On 9/2/2016 at 2:11 PM, Denko666 said:

Mods are not commercial products, they are volunteer work. So don't go expecting After Sale Service. I agree TCA3 is complex, TCA2 was also complex to the untrained eye too... so really, where usage is concerned: RTFM. As for the interface, user-friendliness is an illusion, what works for one won't satisfy another. That said, there are certain design paradigms that in general will make usage of controls easier. IF Allista feels like reworking the UI, i'd say we chip in where we can with code or coin; do you have a Patreon account Allista?

I, for one, am in awe of what this mod does. Especially considering the code and math involved.

Do consider that no-one forces anyone to use this mod, if it's too complex or doesn't work as you expected: don't use it. Maybe Vertical Velocity Control is more to your liking. And also do consider perhaps the most obvious solution of all: if you think it can be done better: do it. It's all open source. Don't know how to? Learn it! 

Thank you for your support, I really appreciate it. I tend to reflect emotionally when faced with an accusatory attitude (or at least something that feels like one). This is not a good thing, I know. Moral support helps to feel confident and cool down. 

And yes, I do have an account at Patreon and would be grateful for any support there as well 

[allista]

Poll: User Interface and Functionality of TCA

After all the discussion I feel the need to get a more detailed and objective picture of usage patterns and current problems of this mod.

I will not guarantee that I will directly implement its results, for I still have my own opinions on the matter; but I also believe there's no smoke without a fire.

So I ask you all to participate.

*the poll will be open at least a month, and you are allowed to edit your responses.

[RedParadize]

Regardless what the poll result is and what is chosen after it, I would like to thanks you @allista for your open mindness. 

My critics might have been harsh but I want to make clear that I have a deep respect for what you did.

[AccidentalDisassembly]

Took the poll; I think some of the questions in there are very valuable, and I wanted to ask some questions of my own based on what I saw in the poll + what I see in the manual, since the poll reminded me of the many functions of TCA that I don't use.

For the moment, the biggest question I have is about engine roles. I wonder if roles couldn't be simplified. Here's how they're described:

Quote

Thrust & Maneuver (_default_): when balancing, TCA tries to maximize the thrust of these engines. In a perfectly balanced ship all such engines should have 100% thrust in the absence of control input. *These engines are used to control vertical speed AND attitude.*

Thrust: a group of engines in this mode is always balanced so that it does not generate any torque. It is mostly useful for jets-based VTOLs. *These engines are used to control vertical speed.*

Maneuver: when balancing, TCA tries to minimize the thrust of these engines. In a perfectly balanced ship these engines produce thrust only in response to control input. *These engines are used to control attitude, and for translation.*

UnBalanced Thrust: this mod is primarily intended for a single-engine configuration like rocket lander or a VTOL-capable plane with a single lifting engine. TCA never tries to balance engines in this mode, but still *uses them to control altitude and vertical speed.*

Manual Control: these engines are never balanced or used to control altitude or vertical velocity. Instead, their thrust may be directly controlled with a slider under "Manual Engines" pane which is toggled with "Show/Hide Manual Engines" button; or from a corresponding engines profile. *HSC, however, uses them for horizontal thrust when needed.*

A couple of things occurred to me here. 

The "Thrust" profile doesn't need to exist. TCA could assume that all engines that are active should be used to control all kinds of speeds, unless the user says otherwise.

Only one option seems necessary here: Prioritize maneuvering or not. I am assuming the difference between Thrust and Maneuver exists for this kind of situation:

1. A craft has two kinds of engine, and one is supposed to be used sparingly.
2. An example would be maybe a craft that has big jet engines for hovering, and rocket engines (or smaller jets) either for lots of power quickly or so that changing the big engines around doesn't make the craft wildly overcompensate.
3. You'd want the jet engines to do everything until they just couldn't, and then the rocket engines would kick in; or the little jet engines would be used for finer control than the big ones could provide.

You might actually be able to eliminate all of those modes, including manual control, if the logic of TCA's pilot assist were reoriented slightly. I think there are a couple of assumptions which are safe:

1. The user probably designs a craft with "modes" in mind and can figure out what to turn on and off to make them happen.
2. Every time the user has TCA turned on, but not switched on full autopilot, it's because she wants something to be balanced.
3. If it's a rocket, she almost certainly wants TCA to make the rocket go in the direction it's pointed on the navball despite unbalanced engines (like for a space shuttle setup).
4. If it's a plane/helicopter/VTOL, she either wants TCA to do the exact same thing - compensate for weird engines so the plane's net thrust vectors will point "forward" - or she wants to do VTOL, STOL, or hovering.

I think TCA can probably achieve all of those things and eliminate some complexity in the process, maybe. This is just me thinking out loud, so please don't imagine I consider this to be some sort of gospel. The logic  might go something like this. It's just a slight reorientation of many of the ways TCA already works:

A. The user sets up the craft so that she can turn on/off engines or groups of engines depending on what she's doing.

B. Having TCA on tries to balance the engines on a craft so that it goes in the direction it's pointed on the navball, which covers unbalanced rockets, except if:

C. VTOL (plane or helicopter or rocket, no difference) mode also gets turned on:

1. TCA looks at the currently active engines on the craft and calculates how much thrust out of which engine, and what attitude, gimbaling, etc. would be necessary in order to make the plane go in the direction the user indicates. There are probably several different control schemes to determine what the user wants. I'm going to try to elaborate on one. All active engines are on the table, with the possible exception of being able to define engines that are used as a last resort/for maneuvering only. If there are any maneuvering engines on a craft, TCA uses those first, and not other engines, when the user wants the craft to do anything other than remain motionless. TCA looks at the direction the maneuver engines are pointed and figures out what kind of maneuvering it could actually do with them; if they aren't pointed backward, for example, it then falls back to "main engines" if the craft needs to move forward. Otherwise, there's an underlying assumption that the user knows which engines ought to be used when, and sets up action groups to turn them off and on as needed. TCA reacts/compensates according to which engines are available and/or by which ones are "maneuver only."
2. TCA assumes that the rest state of the VTOL is a motionless hover unless the user has turned on full autopilot, in which case it's just an autopilot and figures its own stuff out accordingly. The point is to consider motionless hover the rest state while "VTOL mode" is on, and to try to achieve that with whatever orientation the user has the craft in, given the engines TCA has to work with and the direction they're pointing. An "oh crap" button could tell TCA to take control and do whatever it can to return the craft to a rest state, thereupon turning off "oh crap" mode and handing control back to the user, or something.
3. One possibility for interpreting user intent: Pressing WASDQE does what it normally does, and TCA tries to maintain zero motion (gimbaling, max thrust, whatever) while respecting the user's choice of orientation (to help you land on sloped things, for instance). If TCA can't accommodate an extreme tilt, it tries to minimize movement, but slipping will occur. 
4. Since TCA is handling all active engines, it interprets the user's throttle value to mean "make the craft go in the direction it's pointed on the navball at a speed proportional to where I've set my throttle." TCA does whatever it needs to do in order to balance engines so that, if the throttle is at 50% (for ex.,) the craft goes in its indicated direction at 50% of the maximum speed that's achievable while making sure the craft NOT go in any other direction (like vertically, or sideslip). If there are wings, TCA would theoretically recognize that the craft isn't falling very fast anymore, and modify the max thrust of downward-pointing engines accordingly, using more or less rear-pointing engines to continue making the craft go forward. Really, though, in actual gameplay, the user can just turn off their downward facing engines and turn off VTOL mode when they're going forward fast enough to have lift. If there are no wings, the user just keeps VTOL mode on.
5. Since TCA considers a hover to be the craft's rest state, two more keys are needed to tell TCA to translate the craft vertically, which is what happens now via the throttle keys when hovering with some combination of modes. Instead of the throttle - I don't know, maybe Z and X, which then woudn't work for max/min throttle anymore (while vtol modeis active). Dunno if that's possible. Depressing one of those keys (or something else) tells TCA to try to move the craft vertically while the key is depressed. The longer it's depressed, the faster TCA tries to make the craft go up. Same applies to going down via the other key. Letting up on the "descend" key tells TCA "I want the plane to stop moving downward now," and (unless other controls are depressed), TCA tries to return to a hover as quick as it can. An alternative would be to use the Ascend and Descend keys to incrementally change vertical speed, kind of like how the throttle works now when "Auto Throttle" is engaged. Maybe, e.g., press Z once for +1 m/s vertically, X for -1m/s.
6. An additional button maintains a particular altitude, like the follow terrain function; with this turned on in addition to VTOL mode, TCA makes the craft prioritize maintaining that altitude if at all possible; Z and X now change what that altitude is. Throttle still makes the craft go in the direction pointed, but within the new limits established by maintaining that altitude above the TERRAIN, here. Or maybe there's just a button that says "maintain alt and speed" that's kind of like half-autopilot: craft tries to go forward at given speed and maintains altitude (above terrain or as an absolute number), but the user can still use A and D to change the craft's direction? You get the idea.
7. An alternative control scheme: remap WASD to mean "translate the craft in this direction at increasing speed for the duration of the keypress", and some other scheme could be found for "move the craft up and down". Q and E could rotate the craft around the vertical axis or some such.
8. Autopilot functions could also be used in this mode, and they would just take over the keyboard controls, essentially, and you'd have to figure out a good way of inputting values to the autopilot. I'd recommend Atmospheric Autopilot or Pilot Assistant for models, maybe.
9. Maybe there could be an "Oh crap" button that tries to use engines
10. The logic behind all of this basically eliminates the need for all of the "prograde +" and "maneuver +" buttons and whatnot, since the user could just point the craft where it's supposed to be pointed. They might still be useful in a full autopilot mode.

End result: 3 buttons (or 4, with the "Oh crap, stop everything" button) for anything other than complex autopiloted maneuvers. Step 1: turn TCA on. Step 2: turn VTOL mode on. Step 3: maintain altitude button with option for terrain altitude if you want it.

Really, all of this relies on the user occasionally realizing "Aha, I see I can't achieve VTOL at this angle, but if I tip around the rocket or the plane, TCA will try to make me hover."  I think that's intuitive enough, no buttons/controls/knowledge of PID/whatever required, lots less settings to fiddle with to achieve the same outcome. You still COULD mess with all the prograde+ stuff if you open the "fine autopilot controls" window, or whatever, and what I'm saying does not require eliminating any functions, just a bit of re-kerjiggering. I just think there are only so many outcomes the user wants when TCA is turned on... Maybe I've captured them, maybe not. I'm not saying that these ideas are complete, it's really just an exploration of (maybe) a different way of thinking about the whole experience of using TCA. Maybe.

 

 

Edit: Also, one more minor thought. Control over landing gear really should not be handled by TCA, it's annoying, sorry. Just let me control it as the user. In my experience, when testing craft especially, TCA consistently raises the gear at just the wrong moment, and it's not possible to put them back down as my test craft inevitable does a hard landing.

Edited September 4, 2016 by AccidentalDisassembly

[Lvdovicvs]

For long time now I've been trying to reenact the maneuver thrusters behavior like on a ICBM (yep an icbm nut here) but just without anu success. 

Im thinking smth like in here on this Minuteman III animation

Mind the thrusters on the roll maneuver and in the final stage.

Any thoughts anybody?

Edited September 6, 2016 by Lvdovicvs
Typo

[blub01]

not sure if I'm just doing something wrong, but using one engine in manual control mode automatically forces others to have a 100 thrust limiter for me.

[Colonel Cbplayer]

While this is an awesome mod it still has a crowded and overall crap UI

An option to choose what buttons to display would be greatly appreciated

[allista]

1 hour ago, Colonel Cbplayer said:

While this is an awesome mod it still has a crowded and overall crap UI

An option to choose what buttons to display would be greatly appreciated

Have you took the poll then?

13 hours ago, blub01 said:

not sure if I'm just doing something wrong, but using one engine in manual control mode automatically forces others to have a 100 thrust limiter for me.

Could you post some screenshots of your ship and this behaviour; or its .craft file if it's stock? Without it I can't figure what's happening.

On 9/6/2016 at 7:47 PM, Lvdovicvs said:

For long time now I've been trying to reenact the maneuver thrusters behavior like on a ICBM (yep an icbm nut here) but just without anu success. 

Im thinking smth like in here on this Minuteman III animation

Mind the thrusters on the roll maneuver and in the final stage.

Any thoughts anybody?

Sorry, but I can't quite grasp the essence of what's going on in this video. A rocket with a bunch of RCS thrusters pointing in every direction?

[blub01]

6 hours ago, allista said:

Could you post some screenshots of your ship and this behaviour; or its .craft file if it's stock? Without it I can't figure what's happening.

the .craft file on my dropbox

(at least I hope it works this way. haven't done it in a long time).

[Lvdovicvs]

On 9/11/2016 at 8:37 AM, allista said:

Sorry, but I can't quite grasp the essence of what's going on in this video. A rocket with a bunch of RCS thrusters pointing in every direction?

Im sorry. This is quite difficult to explain for me too. Since any rcs for me has shown too weak or to powerful to mimic a PSRE for an ICBM, putting thrusters controlled by TCA instead is more practical. What i mean is I wolud like TCA to have an option to control directional thrust like the rcs of the final stage in the video.

Meaning TCA should activate the "directional thrusters" only when directional thrust is needed, automatically or manually should it be, but not hold active all the time, all the thrusters the user had installed in the craft. 

Hope I explained myself more clearly this time.

 

Cheers

[kerbiloid]

On 11.09.2016 at 9:37 AM, allista said:

Sorry, but I can't quite grasp the essence of what's going on in this video. A rocket with a bunch of RCS thrusters pointing in every direction?

Spoiler

(Not a rocket scientist, but how I presumed to do this if I could make such mod.)

Missile (from top to bottom):

* The missile top is the post-boost vehicle (PBV, bus, ГЧ). (It contains the rocket brain with ICBM magic).
A small stage with a small main engine and RCS in different directions.
It contains mounted warheads which are covered with a shroud or a shell fairing.

Its body is the missile command pod. TCA would live here.
IRL it contains a hyrostabilized platform which is used during all the flight. But it's not very precise (half kilometers or more).
To correct it after the ascent there are astro/radionavigational antennas and sensors. They are retracted. Round hatches around the body - that's where they extend from.
Of course in KSP you just get exact coordinates from API, and don't need this stuff unless you want a scenery.
Also in this missile (Minuteman) the PBV body contains decoys dispenser.
It is like a mini-Hangar with mini-copies of warheads (kilograms or so). Or (in other missiles or in KSP) they may be placed just where the warheads too.

The lower part of the PBV body is an engine section. Several centners-tons of fuel. Liquid (as here) or solid (as, say, on Trident).
This is the tug which precisely targets the warheads after the rough ascent.

 

* 1,2,3 march stages (boosters).
On solid (as in the movie) or liquid fuel. Just common purpose rocket stages.
From 1..3 in different missiles.

 

* A small solid-fuel launch booster.
To throw the missile up from the SILO or rover or submarine.
A flat cylinder about a meter high under the rocket.

-------------------------------------------------------------------------------------------------------------------------------
In KSP you can do something like this (taking this missile as an example).
(Not I say that all of this would be mentioned in TCA. Just an event sequence.)

1. The launch booster ignites, works a second and burns out. Then decouples.
This throws the rocket 50-100 meters high.
It's trivial.

2. First stage main engine ignites.
Simultaneously the rocket turns to required initial heading and pitch.

3. The simplest case: from here up to the finish of the ascent just hold prograde, with no maneuvers.
This is a trajectory with minimal energy loss. Assume that every launch is a launch at max distance.

4. First stage out, decouple it off and ignite its retrorockets if any - to pull it from the second stage engine.

5. Maybe after a 1-2 s pause, ignite the second stage. Keep prograding.

6. When altitude is above dense atmosphere (40-50 km), decouple the head shroud (or fairing shell).
(Extend antennas and navigational sensors and start measuring you exact position. But in KSP of course this is just a scenery.)

7. At last you ignite the last stage (3rd in this movie).
Keep prograding, but every tick roughly calculate how far would a warhead land from the average target position if stop the engine right now.
Vacuum part of calculation here looks pretty easy (just an intersection of ellipse with sphere). Atmospheric is the most tricky, like Trajectories mod.

8. Keep prograde and keep running the engine until the distance stops decreasing. Then shutdown the last march stage engine.
If the engine is liquid, just do it.
If solid, it's a problem. Usually they either cut off the nozzle, or make holes in the stage to let the exhaust get out and drop pressure, or combine different kinds of perversions.
Maybe put powerfull retrorockets and ignite them. Maybe just deny the last stage to be solid or force it's cfg to be stoppable.
In onew word: shutdown.

9. Decouple the useless 3rd stage and post-boost vehicle.
Now the PBV is roughly targeted somewhere between target on the planet surface.
Store your vertical angle in memory.

10. Calculate a desired velocity vector to make it fall at the first target point starting from this position.
Subtract current velocity vector and the desired, rotate the PBV into desired angular position with RCS, ignite main engine (T/W = kilonewtons per first tons).

11. Calculating every tick the distance between the estimated landing point and the target position, keep modifying your desired vector.
Keep doing this until the estimated distance stops decreasing.

12. Rotate you PBV to the angle stored in memory (but in opposite direction) - to allow the warhead get into atmosphere with nose.

13. Decouple the first warhead. Notice that this makes the craft (i.e. PBV) unbalanced, so this is exactly what TCA is presumed for.
With RCS pull PBV back not to disturb it.

14. Repeat steps 10-13 for the rest targets and warheads.

Notice that:

0. So, before the launch you should know the optimal pitch angle to reach maximum distance and maybe set of azimuths for different directions.
Either calculated, or experimentally found for exact rocket and insertable into an edit field.

1. Warheads are dumb pieces of metal, they have no engines, flaps, brains, they don't maneuver.
Unless you want to make them maneuverable, then you can add flaps (not engines).
In the movie they have two wannabe microengines (carbon dioxide or so) making them to rotate: for stabilization and heat dissipation. Probably useless in KSP, a CoM position in warhead's cfg rules here.

2. While doing steps 10-14 you can from time to time decouple false warheads.
If using BDArmory this can be a deal, as BDArmory radars will treat them as targets if they are defined CommandPods.

3. In KSP there is no any burst options except "fall and kill with your weight".
BDArmory allows to make warheads (Say, North Kerbin Dynamics mod contains one). In this case they should be launched not with "decouple" action but with "fire missile" action (which is decoupling itself).
Also in case of BDArmory the PBV should contain a part "Weapon Manager" to make this available. Or its MODULE from cfg, this worked, too.

4. Target positions should be not far from each other: tens kilometers or so.

5. Also you can implement more simple additional mode: MIRV without I.
Instead of targetting every warhead, target the whol PBV and slowly rotate it with RCS. Then one by one launch warheads. Centrifugal force willl pull them aside.
This is like an emergency mode.

6. 3 stages is way too many for Kerbin. 2 stages are fine. Most of soviet missiles and Titans are 2 staged.

7. Keep in mind that warhead are not necessary placed above the PBV body (push), they often are placed below PBV (pull).
So, maybe there would be a checkbox: "Reverse PBV axis direction after decoupling from rocket?" Or just calculate this automatically.

 

Edited September 12, 2016 by kerbiloid

[RedParadize]

1 hour ago, kerbiloid said:

  Reveal hidden contents

(Not a rocket scientist, but how I presumed to do this if I could make such mod.)

Missile (from top to bottom):

* The missile top is the post-boost vehicle (PBV, bus, ГЧ). (It contains the rocket brain with ICBM magic).
A small stage with a small main engine and RCS in different directions.
It contains mounted warheads which are covered with a shroud or a shell fairing.

Its body is the missile command pod. TCA would live here.
IRL it contains a hyrostabilized platform which is used during all the flight. But it's not very precise (half kilometers or more).
To correct it after the ascent there are astro/radionavigational antennas and sensors. They are retracted. Round hatches around the body - that's where they extend from.
Of course in KSP you just get exact coordinates from API, and don't need this stuff unless you want a scenery.
Also in this missile (Minuteman) the PBV body contains decoys dispenser.
It is like a mini-Hangar with mini-copies of warheads (kilograms or so). Or (in other missiles or in KSP) they may be placed just where the warheads too.

The lower part of the PBV body is an engine section. Several centners-tons of fuel. Liquid (as here) or solid (as, say, on Trident).
This is the tug which precisely targets the warheads after the rough ascent.

 

* 1,2,3 march stages (boosters).
On solid (as in the movie) or liquid fuel. Just common purpose rocket stages.
From 1..3 in different missiles.

 

* A small solid-fuel launch booster.
To throw the missile up from the SILO or rover or submarine.
A flat cylinder about a meter high under the rocket.

-------------------------------------------------------------------------------------------------------------------------------
In KSP you can do something like this (taking this missile as an example).
(Not I say that all of this would be mentioned in TCA. Just an event sequence.)

1. The launch booster ignites, works a second and burns out. Then decouples.
This throws the rocket 50-100 meters high.
It's trivial.

2. First stage main engine ignites.
Simultaneously the rocket turns to required initial heading and pitch.

3. The simplest case: from here up to the finish of the ascent just hold prograde, with no maneuvers.
This is a trajectory with minimal energy loss. Assume that every launch is a launch at max distance.

4. First stage out, decouple it off and ignite its retrorockets if any - to pull it from the second stage engine.

5. Maybe after a 1-2 s pause, ignite the second stage. Keep prograding.

6. When altitude is above dense atmosphere (40-50 km), decouple the head shroud (or fairing shell).
(Extend antennas and navigational sensors and start measuring you exact position. But in KSP of course this is just a scenery.)

7. At last you ignite the last stage (3rd in this movie).
Keep prograding, but every tick roughly calculate how far would a warhead land from the average target position if stop the engine right now.
Vacuum part of calculation here looks pretty easy (just an intersection of ellipse with sphere). Atmospheric is the most tricky, like Trajectories mod.

8. Keep prograde and keep running the engine until the distance stops decreasing. Then shutdown the last march stage engine.
If the engine is liquid, just do it.
If solid, it's a problem. Usually they either cut off the nozzle, or make holes in the stage to let the exhaust get out and drop pressure, or combine different kinds of perversions.
Maybe put powerfull retrorockets and ignite them. Maybe just deny the last stage to be solid or force it's cfg to be stoppable.
In onew word: shutdown.

9. Decouple the useless 3rd stage and post-boost vehicle.
Now the PBV is roughly targeted somewhere between target on the planet surface.
Store your vertical angle in memory.

10. Calculate a desired velocity vector to make it fall at the first target point starting from this position.
Subtract current velocity vector and the desired, rotate the PBV into desired angular position with RCS, ignite main engine (T/W = kilonewtons per first tons).

11. Calculating every tick the distance between the estimated landing point and the target position, keep modifying your desired vector.
Keep doing this until the estimated distance stops decreasing.

12. Rotate you PBV to the angle stored in memory (but in opposite direction) - to allow the warhead get into atmosphere with nose.

13. Decouple the first warhead. Notice that this makes the craft (i.e. PBV) unbalanced, so this is exactly what TCA is presumed for.
With RCS pull PBV back not to disturb it.

14. Repeat steps 10-13 for the rest targets and warheads.

Notice that:

0. So, before the launch you should know the optimal pitch angle to reach maximum distance and maybe set of azimuths for different directions.
Either calculated, or experimentally found for exact rocket and insertable into an edit field.

1. Warheads are dumb pieces of metal, they have no engines, flaps, brains, they don't maneuver.
Unless you want to make them maneuverable, then you can add flaps (not engines).
In the movie they have two wannabe microengines (carbon dioxide or so) making them to rotate: for stabilization and heat dissipation. Probably useless in KSP, a CoM position in warhead's cfg rules here.

2. While doing steps 10-14 you can from time to time decouple false warheads.
If using BDArmory this can be a deal, as BDArmory radars will treat them as targets if they are defined CommandPods.

3. In KSP there is no any burst options except "fall and kill with your weight".
BDArmory allows to make warheads (Say, North Kerbin Dynamics mod contains one). In this case they should be launched not with "decouple" action but with "fire missile" action (which is decoupling itself).
Also in case of BDArmory the PBV should contain a part "Weapon Manager" to make this available. Or its MODULE from cfg, this worked, too.

4. Target positions should be not far from each other: tens kilometers or so.

5. Also you can implement more simple additional mode: MIRV without I.
Instead of targetting every warhead, target the whol PBV and slowly rotate it with RCS. Then one by one launch warheads. Centrifugal force willl pull them aside.
This is like an emergency mode.

6. 3 stages is way too many for Kerbin. 2 stages are fine. Most of soviet missiles and Titans are 2 staged.

7. Keep in mind that warhead are not necessary placed above the PBV body (push), they often are placed below PBV (pull).
So, maybe there would be a checkbox: "Reverse PBV axis direction after decoupling from rocket?" Or just calculate this automatically.

 

I fail to see what this have to do with TCA. What you are looking for is a RCS part that have exhausts around it and a good sound pack / FX for it. TCA will interact with it just like the rest of the part.

[kerbiloid]

57 minutes ago, RedParadize said:

I fail to see what this have to do with TCA. What you are looking for is a RCS part that have exhausts around it and a good sound pack / FX for it. TCA will interact with it just like the rest of the part.

I'm not looking for, I just described what Lvdovicvs probably meant as I hope to make on my own with kOS.

Edited September 12, 2016 by kerbiloid

[Denko666]

Hey @allista while looking at what made KSP crash this time. I found this:

[WRN 18:20:23.435] File '/home/steam/.local/share/Steam/steamapps/common/Kerbal Space Program/GameData/ThrottleControlledAvionics/Plugins/../Throt
tleControlledAvionics.user' does not exist
[LOG 18:20:23.435] [ThrottleControlledAvionics: 18:20:23.435] Unable to read /home/steam/.local/share/Steam/steamapps/common/Kerbal Space Program/
GameData/ThrottleControlledAvionics/Plugins/../ThrottleControlledAvionics.user

It's probably not what caused the crash. But regardless: do you know how to solve this?

Cheers!

Edited September 12, 2016 by Denko666