allista

RoverLander may be resized up to the size4, but in career mode this option should be unlocked in the TechTree (see the picture). Does it fit by dimensions displayed in Vessel Info window and in part menu of the Lander?

Thanks! I've imagined just something like this. Will look into NavHUD's code) Ah, that's the hard question They are from my first mod -- the Hangar. But from the development branch; I've been trying to release a new version for several weeks already, but my main work (and TCA in part) keeps me from doing this. Too many things to check...

Good to hear it works While testing, I myself sometimes forget to enable TCA before launch, or disable it hitting 'y' twice, or hitting 'y' out of habit after reverting flight when TCA is already enabled because its state was saved in config... Maybe it was just one of such cases

Hm... that's strange, I'll investigate the matter. I've never used ISP scaler, but a quick glance into its code shows no obvious problem, as the Scaler modifies maxThrust which TCA reads from the engine each frame.

I haven't tested it, but there should be no problem: TCA computes engines' limits each physical frame based on thrust vectors each engine part provides. So as soon these vectors move (e.g. Gimbal moves them too) TCA accounts for the change and recalculates limits accordingly.

Not by itself -- it only considers engines. But if the additional torque is less than torque from engines, enabled SAS should compensate it with TCA. In the legacy forum thread while testing the beta version of TCA VDNKh said:

Yea, I wanted to say the same: It's a little more complex, but non the less doable. And I thought many times about making TCA to be a part, or a module added to cockpits with MM, but in the end decided otherwise. Anyway, thanks for the suggestion, I'll implement it in the next release.

I'm still unable to reproduce this, but there definitely is some strange problem between mesh colliders, EVAs and wheels. To my belief this problem causes both the no-friction bug and kerbals that appear as free-falling while standing on mesh colliders like the one at the top (slopes belong to the same collider, btw). It appears as if collision is only sporadically detected while there's not enough relative speed between two colliders.

It is. For now, through the config file: open the GameData/ThrottleControlledAvionics/Plugins/PluginData/ThrottleControlledAvionics/TCA.glob file in a text editor and find the line "TCA_Key = y"; change 'y' to any printable key you want. Key combinations and special keys are not yet supported, but I'll add them in the future, as well as in-game key-binding changing.

KerbalStuff adds all new mods to CKAN automatically. NetKAN had probably not indexed it yet, though. I'll check NetKAN repo... UPD1: KS bot submitted the pull request a day ago, but it is still hanging there among other 12. NetKAN is not fast, we need to wait a little longer. UPD2: I've added a handmade .netkan file and requested a merge. This file fixes errors introduced by the KS Bot, and thus should (I hope) be accepted faster.

Yea, it would be great, but there is an intrinsic problem with this two: to maintain orientation MechJeb2 uses a vector PID-controller that is tuned in real time depending on engines' torque (well, engines, r.wheels, lifting surfaces... MechJeb is thorough and tough!) and inertia tensor of a ship. But TCA changes engines' thrust (and thus torque) relatively fast, and in many cases it causes self-excitation of the TCA-MechJeb system. The stock SAS works better as it, unlike MJ, does not try to predict ship's movements, using three separate PID-controllers for pitch, yaw and roll with hard-coded coefficients. With such heavy and complex ship, I would turn off the auto-tuning in TCA and try to lower the Steering Gain and P and I values of engines' controller. The ship may become slow in response, but steady with MechJeb. In my tests I had experience of successful tweaking TCA to work with MJ on heavy and very wobbly (not many struts) rocket. Oh, and in my experience landing manually with TCA is a relatively easy task. I've landed a heavy SSTO to the Mun using MJ for targeting and deceleration with main engines and TCA with vertical thrusters for final descend.

Yea, and ferram has already fixed this in the code, but there was no release with the fix yet. I've wrote to him, asking to release the fix. But until then you have to remove BB for the Hangar to work properly.

Stable TCA-2.0.0 may be found in the new forum thread

Throttle Controlled Avionics - Continued real-time engine balancing, attitude and altitude control, VTOL autopiloting Originally created by qfeys and Zenka Current development and maintenance: allista TCA is a plugin that enhances the attitude control of a ship by dynamically changing the output of its engines and RCS thrusters. Even with most unbalanced designs TCA maintains stable flight and quick precise response to user or autopilot input. TCA also provides many sophisticated autopilot programs based on this core functionality, including waypoint navigation and automatic landing. It is also fast enough to simultaneously control a whole squadron of ships without much overhead. First read, then fly! TCA Manual First read, then fly! Support me on Patreon Features Functionality: Simultaneous control over multiple vessels. Realtime RCS and engine balancing. Multiple engine roles and engine profiles. Full support of slow engines (jets, propellers, etc.) Thrust attitude control. Hovering control. Many sophisticated autopilot programs. Orbital maneuvering independent of command module orientation. User defined macros. Technical: Both the Toolbar and the stock AppLauncher are supported. Per-vessel/per-save configuration profiles and custom presets. In-game configurable key binding. Full career mode integration (see below). Introduction to TCA2 New Features in TCA3 Launching shuttle with TCA Flying Harrier-like VTOL plane with TCA New orbital autopilots in TCA 3.2.0 TCA Modules in Tech Tree Downloads and Installation !!! ModuleManager is required but not included !!! SpaceDock Page GitHub Releases Source Code If you're upgrading, DELETE the old version before installing a new one BUT do not delete the TCA.conf and config.xml files to preserve your settings. ChangeLog Acknowledgments: First of all, many thanks to qfeys and Zenka for creating the original concept and implementation. Without them TCA would not exist. And I want to express extreme gratitude to @smjjames, who helped me so much with the testing of TCA3 and proposed countless improvements. Without it this version would never have come to a release! My patrons on Patreon. Thank you for your support! Kevin Casey Bob Palmer Ryan Rasmussen Matthew Zaleski Bart Blommaerts eL.Dude Layne Benofsky Igor Zavoychinskiy Issarlk Meiyo BP Jenna Mitchell Squiddy Ted Achenbach SCESW Patrice Hédé Steve Victory Also, here are the mods whose code and ideas were used in one way or another: Hangar MechJeb2

Maybe just a couple of screenshots like last time? The problem is definitely not in the absence of docking port, as orientation is defined by the root part, whatever it is... Well, until I publish the fix, it is defined not by the root part, but by the first part (which prior 0.90 was always the root one), but it's still doesn't matter what that part is. Resizable parts should not be a problem either. There's probably a mod conflict like the one with BetterBouyancy or that was with ScienceAlert. Send me the output_log.txt (Player.log on Linux) and I'll see what is happening. - - - Updated - - - No, this option adds a start velocity to a vessel that is launched from a hangar. It is for the probes without RCS mainly.

I've found the problem. It was a hidden incompatibility with the 0.90 API. I'll publish the fix ASAP. But that still leaves the problem of using such ships as your lander with inline hangars. Currently you'll still need correctly oriented root part. I'm trying to solve this problem as well, but that'll take time. Can't say much without seeing the designs you use here. This may be the same problem as with the lander, for all I know.

I've tried your design and this is definitely a bug in the Hangar. I'll investigate it thoroughly. Thank you for the report and your tests!

With the smaller hangar the problem is indeed orientation of the root part. It is a problem with such designs that I don't know how to deal with yet. I mean it's not clear how to automatically determine the best orientation of a launched vessel. So for now I just use the Vessel.transform which is equal to the rootPart.transform. But with the bigger hangar it does look like a bug to me. I'll try to reproduce your design as closely as possible and check. Meanwhile do note, that dimensions indicated in the part menu describe the bounding box of the hangar space. They may be used only for approximate reference. With inline hangar you have hexagonal space which is much smaller than its bounding box. So maybe, just maybe, your lander touches one of the side walls of the hangar space when it is positioned at the launch point inside the hangar. That's the normal reason of rejection. - - - Updated - - - I'm considering it, but the problem with friction is bigger than that, so I would rather solve it.

Thanks! Yea, I see the problem. Sorry to forget about smaller displays. I'll place the help text into a scrolling area and made a check for screen dimensions.

Maybe. But presently only the bonesbro took the effort to make the first desaturated textures which I then used to support the Desaturated Pack. I'm no modeler and have no proper knowledge or skill in texturing. BTW, as the poll goes, it seems I have no choice but to make the grey textures default.

Thanks! It's good to know that it does I don't have the resources for proper testing -- too many parameters to check all possible combinations

This issue is a mystery. I've implemented a workaround long time ago and never touched it since, but from version to version and from setup to setup it appears again spontaneously. And I cannot figure why: wheels' friction is increased on contact with the hangar, I've checked many times, it is. But sometimes for some unknown reason it gives absolutely no effect. Unity docs state that the way I manage wheels is the only correct way, so I guess it's something that squad does under the hood. But what exactly I also cannot find out, and believe me, I tried long and hard

Nope, Hangar is not balanced for any particular density. It reads the density from ModuleAsteroid after asteroid creation (when it is first loaded, not when you start tracking it), so if a mod modifies ModuleAsteroid.density value before this, the asteroid becomes heavier, which means more Rock, but the same volume. But if a mod tries to modify density afterwards, there will be conflict with my AsteroidInfo module, and, probably, the density will not be changed at all.

They do; in fact, all conversions are mass-conserving. So, taking into account that asteroid density is constant in KSP (0.03t/m3), larger mass => more resources, more volume.

Do propose a way to determine this in general (rockets, many-pod ships, rovers, etc.), and I would gladly implement it But honestly, I don't see a problem: turn on the Show Directions in Vessel Info window in editor and use re-root if necessary. Also don't forget the 'Spacebar' shortcut to set default part orientation. And use appropriate editor: rovers should be built in SPH, rockets in VAB and so on.