mizo

What I think is really missing in NP right now are 5m engine adapter plates, of the sort you can place multiple smaller engines on a bigger tank. A 4X2.5 to 5m adapter would be pretty cool, as would be an adapter for a large number of 1.25m engines. I think the main benefit for it I see right now is that KerbCom Avionics can make very good use of multiple engines.

Well, what he probably needs to do is to include control for the SRB gimbals, but what I am saying is, the plugin would still probably be useful if it only ignored SRBs for now. Most designs only include them as boosters for the early part of the flight.

Well, they are balanced in the sense that the parts weights and engine TWR/Isp are alright, but it does add a lot of capability to the game, so in another sense it can make the game a lot easier.

Is it possible to just ignore the SRBs for now, and let it have the stock engine control? I think it would still be very usable if it only did that.

Thank you, you are awesome!

Is it just me that thinks that the low profile bases are still too heavy and thick?

Tiberion did you get my report about the Odin RCS Pack having one thruster missing?

Yeah, the problem is that after the fairing base, I have to place an engine adapter plate (a 3.5 meters to 5x1.25m engines) and this plate is the same radius as the tank itself, which is slightly bigger than the fairing base. The problem is that the fairings generated are unnecessarily bulky, and it should be possible to streamline them more without any clipping, but it just won't let me to.

Are these inline fairings also intended in the future to be used as interstage separators? Right now the low profile bases are still too bulky for that, and they are not generating a very streamlined fairing design.

Second this motion. For some reason, the coefficients are listed twice on command pods, wasting a total of 6 lines.

Yeah, to my surprise, I thought that worked. Anyways, that is not a good idea anyways, since by the time you reach the mun's soi, you might see significant errors in the periapsis height. And you can timewarp so fast that it should not be an issue.

I think I misunderstood you then. I thought you were proposing a solution where you would somehow actively dampen the SAS oscillations. Anyway the main problem I see with solving the system every update is with regards reliability. With it being done once per startup, and ignoring structural flexing altogether, you get a sense how the ship handles from launch, and there is not much variation there, and chances of something then going wrong deep into the mission are low. Now doing that every update and accounting for strut flexing introduces a lot of unknowns and possibilities of failure there. For example you might be introducing new paths of positive feedback. Or also depending on a combination of user input, attitude, flexing and/or damage to the ship, it can fail to solve the system and that then leads to loss of control.

You could for example immediately create a circularization maneuver at the next periapsis. Even though right now you are in kerbin's SOI, the maneuver will be created on the next mun Pe regardless. Or you could just wait for the SOI transition, adjust your periapsis to your liking, and then execute the circularization maneuver as before.

By the way, with FAR, you can control how much lift you get from the capsule by controlling your angle of attack, so you can actually resist to some degree both being sent into the lower atmosphere too soon and being bounced out altogether. You can also steer the capsule to control it's heading somewhat. Check this video I made some days ago. It used a version of FAR which was calculating too much lift for the mk1-2 pod, but the principles are the same. You are just not going to get a performance this good from current FAR, but you can still work with it. It was made using FAR and Deadly Reentry, and it was possible to accomplish reentry with no heatshielding whatsoever, and that with minmus reentry speeds.

I see. Well I did not realize you were encountering wobble caused by your code itself. I was talking more in general about SAS and mechjeb autopilot induced wobble. But still, I think structural flexing shouldn't matter much, I mean I suspect there should have too much wobble for it to mean anything. About the shifting CoM I agree it's a problem, but how hard for example would it be to solve the system with CoM being another free variable?

Here is the one I did, though it uses some parts from NP and KW: The docking port is from bobcat ind. It has a very low CoG, and it survives pretty rough landings with some horizontal speed.

Yeah, well, I think your current implementation of resolving every frame might be too heavy handed, and tbh I don't see much point in it. I am very skeptical you might be able to solve the current wobble problems with it. I think the solution might have to be in the direction of doing some structural analysis and/or empirical evaluation to find resonance peaks, and then to avoid those frequencies in the flight computer in the first place, maybe by notch filtering them out for instance. So you might be revisiting that in the future, in which case solving the system 100 times during startup is peanuts compared to every frame

Well, one aspect of this plugin I like is giving a step towards doing away with the silly situation of having those reaction wheels for everything. The current plugin already allows for performing a mun landing without any use of reaction wheels or RCS during powered flight, which I think is pretty great. The only issues are lack of gimballing and problems regarding reliability, esp regarding what japa said, the solver reaching an invalid state and making all engines go off.

Yeah, I did not report this problem initially because I figured it was a problem in your simplex solver code, and you said you were ditching it anyway for the next release. I just recently also realized that the rcs pack I was using on some other craft had one of it's rcs ports missing from their model, so that probably explains the other instances of this hang I experienced. By the way, I wonder, how complicated would it be to modify your code so that it does not attempt to solve for dimensions which give too few degrees of freedom to begin with? For example, in the hover case with only engines pointing straight down, it would ignore roll and solve it only for pitch/yaw and forward motion.

By the way, I reproduced the hang again today. It happened with a small lander with a non-optimal rcs configuration. Four rcs 4-pack around the center of mass. The lander had a really tight profile where it was balanced pretty reasonably in the entire range between full fuel and no fuel. I guess there was not much point really on running the rcs balancer on this craft, but I wanted to see if it fared well, but alas it hanged as soon as I hit the 'RCS linear priority control button', and 'Enable RCS control' wasn't even activated! No error logs related to this fault were produced. The game hanged up pretty well, had to kill it on task manager using the keyboard only, because clicking anywhere with the mouse would bring the hanged game into focus instead.

There is a problem with the Odin flight pack, one of the rcs thrusters is missing. I spotted that while playing around with RCSbuildAid.

By the way, what really get's screwed by this plugin are the various plugins that depend on estimating how much main engine thrust you have, like engineer and mechjeb vessel info. They really don't like engines pointing directions other than straight down. Also, another related issue is that, even if the bulk of your engines are pointing straight down, with only a few puny ones giving you roll authority, mechjeb landing autopilot does not account for the afflicted control losses, it assumes that all engines are running at the power of thrust specified, and so it massively overestimates how much thrust it has control over. It seems that the autopilot runs pretty much open loop, and it's pretty aggressive in it's attempt to be delta-v efficient, and needless to say it has disastrous results.

Yeah, the current version works fine in 0.21 at least for the engine control modes. RCS modes seem to work but the game hangs completely not long after I enable it.

That would be nice, but currently there is no way to do this if you want to maneuver without also translating forward, since you have to apply some throttle for it to do anything. I don't know if ZRM can modify the plugin so that it would control the attitude even with throttle completely off.

Ops, sorry about the privacy setting on the video, should be fixed now. Thanks Lurven!