ZRM

Have you tried decreasing the torque sensitivity/strength like I suggested previously? If you put it at around 5%, although the control is sluggish, it tends not to be unbalanced since the input more closely matches the output throttles. I have a jet-powered VTOL that I have used successfully for regular trips around Kerbin, though it doesn't have wings so it's a bit slow since it's limited to vertical thrust only.

I'd just like to clarify that AFAIK there is not much in the way of bugs right now other than those present in KSP already that have manifested themselves due to the boundaries the project is pushing. As helldiver said, the main focus right now is on the MFDs, specifically all of the texture assets helldiver needs to produce for each display mode. I have been explaining the way all the textures are composited with masks. Once I get the new LRBs working correctly I will be focussing on adding the secondary functionality to the cockpit interior, including clickable switches and buttons, the other two Kerbals and the click-to-get-a-better-view windows.

Sure, if it's that big a deal I can try to provide two setups - one that is designed for MFS, and one for standard fuel, though this will probably require changes to the engine properties to balance the gameplay, and the practical range and the payload limit of each version of the shuttle will probably differ. Don't expect a stock-tailored version in the first release though. In the mean time editing the configs should suffice. Also, be aware that a stock-fueled EFT will contain very little fuel for its size - probably around that found in the stock Jumbo 64 tanks, otherwise it would be too heavy to launch.

No. Not until it's finished. I'm not releasing something half-baked only for the people that begged for its release to complain about missing features/bugs/glitches/unbalanced gameplay etc. I'm sure Helldiver feels the same. That is very doable, but is something that can probably wait until after the first release, especially if separation motors and an explosive decoupler work well enough, which they seem to be right now. Nope, you did not get lucky with the cameras. The original camera positions gave a rather messy view of parts of the dash. Luckily the cameras are customisable, so I moved them up to points on the forward windows in front of each Kerbal, and oriented them and changed the FOV to fit in their heads at this close range. You may notice the slight jaunty angle to it. Normal Kerbal cams fit in the most of the rest of the body as well as the head, but there is no clean way to do that in the confines of this cockpit. The camera positions for the rear two Kerbals should be easier to set up.

According to the video (if you wait till the end) they are radial thrusters from LackLusterLabs.

What I plan to do is make the dV realistic for the design, but playability takes priority if it turns out the design would make some aspects not as fun as they could be. So I will first figure out the volumes of fuel that can be stored in the shuttle, then derive everything else from there, including the required engine thrusts, ISP curves, practical range (which may be interplanetary, Kerbin SOI, or less), etc. I would really like to use Modular Fuel System, since it would force the correct use of the EFT, SSMEs and OMSEs, as well as make the fuel capacity of the EFT realistic (an LF/O EFT would be much smaller than the current one). It would also make for some interesting gameplay regarding any refuelling trips. If you are worrying about any effects MFS would have on other parts, it can easily be restricted to work on only select parts. Also, compatibility with, for example, Kethane, should be straightforward via a combination of Module Manager and the recent improvements Majiir has made to Kethane's extensibility.

I could, but there would not be much point, as the current fuel load and LRB engine arrangement is temporary. As such any dV I come up with (which would require me to go and add KER or MJ to the installation) would likely be quite different from the final value, which is what you're really interested in. An LRB currently does not come with an engine of its own - for the time being I am using stock Mainsail engines, which are a bit too powerful and thirsty. Similarly, an SSME is currently equivalent in ISP and power to an LV -T45, and an OMS engine is equivalent to an LV-909. This is very likely to change significantly. The current configurations are just to get everything in the right ballpark (in some cases a very large ballpark) whilst features are added so that they can be tested. Once we reach the feature-complete stage I will focus entirely on balancing all the stats, including the dV. The final system will very likely be reliant on Modular Fuel System for H2/O2 in the main tank supplying the SSMEs, and LF/O in the orbiter supplying the OMSEs. The engine stats will be changed to reflect their fuel input. I will also be basing the fuel amounts on volumes within the parts. Anyway, here's a few screenshots for you all. Edit: By the way, the crew count is temporary. I have yet to put the other two Kerbals in.

Great! Thanks for that. I'd always been amazed that no one had yet made such a mod. I had it on my to-do list. Now I know it exists. After the first KSO release (since, as I said, the brakes work well enough), I will look into adding this to the shuttle. By the way, the shuttle has recently performed its first successful ascent, orbital insertion, deorbit, re-entry and precision landing on the KSC runway. The ascent used a launch vehicle consisting of the EFT and LRBs you have seen previously, and played out very much like a Space Shuttle launch. The shuttle circularised at 80 Km. Re-entry was achieved at a constant pitch of 10 degrees (though a higher pitch would probably be more realistic). The landing worked first time, touching down on the dotted line at 192mph and braking well before the end of the runway. No parts malfunctioned or broke, and no debris were left in orbit. Sorry, I have no screenshots - I was concentrating too much. KCA worked well throughout the flight, balancing the engine thrusts at all stages of the launch, and orienting the shuttle in orbit using RCS.

The "R1A Compressed Air Thrust Nozzle" is a standard B9 part. It's fueled by IntakeAir instead of Monopropellant. But, as I said, using RCS would probably not wholly fix the problem, though you can try. Best to try and tweak the settings or switch to rocket engines.

I can see two things that may be responsible for your problems: You are using jet VTOL engines. These engines have a substantial spool-up/spool-down time. As such they probably don't react quickly enough to the changes in input provided by KCA at high torque sensitivities as the SAS tries to keep the vessel level. My first recommendation is to try decreasing the torque strength significantly in KCA settings so that its inputs to the engines do not vary as much (so the output should more closely match the input, and not oscillate as much). I have had good success with jet VTOLs after decreasing their sensitivities. If that fails, you can replace them with rocket VTOL engines, which do not lag and should provide perfect control, but at the expense of much lower ISP. The ideal solution is to add B9 air-fueled RCS ports, as these approximate real life jet-based VTOL systems. In real life a single engine provides the main body of lift, as well as high pressure air to attitude control nozzles around the craft that can change their output instantly by changing their apertures. The problem with this approach would be that KCA would still preferentially vary engine thrusts instead of using the RCS ports, since it does not yet have any knowledge of the laggy behaviour of jet engines (fixing this is feasible, though I do not have much time to work on this currently). Your vessel includes a lot of aerodynamic static and dynamic surfaces. KSP aerodynamics can behave very unrealistically, especially when any surface moves backwards. This could be creating forces that the system cannot fully counteract.

Thanks for the feedback! The more feedback I get the more reliable/stable/useful I can make this mod. I haven't really tested much for compatibility with MechJeb. Not sure what would be breaking the auto-staging. Does it break all auto staging, or just some stages? KCA does not directly affect staging, so no, this is not expected. Something must be breaking inside MechJeb somehow when it encounters my modifications. On an unrelated note, IMO MechJeb needs either an overhaul or a replacement at some point - it should take some tips from real world and simulator control systems to make itself more reliable, useful and easier to use. It should also stop relying so much on statistics gained from the internal data of stock KSP modules and assumptions of how control affects vessels - this restricts its compatibility with unusual designs and plugin-based propulsion or control methods, such as KCA. Regarding the additional context information being available at all times, that is expected, and due to augmentations KCA makes to parts at load-time in order to allow KCA enough control access to work. I have previously tried making it so that parts are augmented on-the-fly by the onboard KCA module (so vessels without KCA modules would not be augmented), but it proved too unreliable. These augmentations should not affect stock behaviour other than gimbals, which have been upgraded to correct defective stock gimbal behaviour. Specifically it fixes the issues where stock gimbals work against you when placed above the COM, and they do not react to roll control input. Also, don't forget to try out the engine balancing modes in KCA. See the new video in the OP for an example.

Using a parachute for braking is not an option right now, as the KSP parachute module automatically "deletes" the parachute once you touch the ground. Anyway, the brakes are good enough right now.

Your video is now in the OP. Thanks again for that.

Well, if you go back a few pages, you can see screenshots from inside the cockpit in space. Well, the current plan is to make it so that the gimbal range on both engines is purely there to change attitude and counter any changes in the COM due to fuel flow. It should not be used just to get the engines pointing roughly at the COM. That is the job of the engine pivot hinges. Luckily it will only be an action key or two to get the engines pointing in the right direction, since pivot presets can be written into the config file. Making use of the pivots like this ensures that the gimbals have the approximately the same freedom of movement in both negative and positive pitch directions for attitude changes. If you can bear to trawl back through this thread, you will find that the shuttle is split into several parts, all attached by the normal attachment node system (for the time being - I am working on an improved system). The shuttle itself comprises of a maximum of 20 parts, if you include the avionics in the nose cone and the docking adapter. The reason that it is split into so many parts is partially due to artificial limitations needlessly imposed by KSP, and also partly due to some inaccurate advice helldiver received early on in the modelling process. It also helps to have the shuttle split into several parts when you consider the variety of status information and buttons you will find in the context menus. If it was one part that context menu would be very long, and some of the menu items would be identical due to there being more than one of some modules on the part (such as the engines). If necessary I can try welding parts together at a later date. That is something to consider after the first release, however.

Yes, fuel flow seems to be working fine. I didn't even do anything special to get that to work. As soon as you have all of the components for an MFD display at a state where the structure (i.e. hierarchy of graphical parts) is final (but not necessarily the layout), and every part is usable, please send them to me so I can work on the code required ahead of time. It does not matter if the layout or sizes are not exactly right or the graphics are placeholder, as long as all of the required components are there. That way there can be a bit more of a "pipeline" of productivity and the final MFDs can be set up nearly as quickly as you finish them.

Thanks for that link. Looking at it, it looks like it uses exactly the same technique I am testing, only in a very limited form. In reality invisible auto-struts are quite simple code-wise. Why Squad haven't used similar techniques already to solve the wobbly rocket problem, I don't know. Once I have this working properly for the decoupler using raycasts to determine strut locations, extending this to make much more realistic and rigid rocket part stacking as well as to allow cyclical vessel structures (such as several decouplers on one layer) should be trivial.

Yes. I'm also performing a feasibility test of a custom decoupler module that actually attaches to the shuttle at all 3 support points. Currently struts are required next to the lower support points due to the inability of creating cyclic attachment graphs in the VAB/SPH.

Yes, it should be. The stock navball is a prop, and is instantiated in a cockpit via settings in the config file for the cockpit. So you could edit the config to remove the stock navball and add another one. Helldiver would have to provide a suitable model for the navball holder so that the navball appears with the same visibility as the original one. You could also use a similar technique to add standalone MFD units to stock cockpits. Alternatively you could just use my yet-to-be-released material overriding plugin I have been developing for the shuttle to make the navball emissive and use Helldiver's textures. In this case the model would be the same one as the stock navball.

You may want to read this post. Basically, the answer is no, as the custom graphical MFDs are coming along nicely (see previous screenshots for an example of the functioning mockup PFD that is not representative of final assets).

Thanks for that! Very nice demonstration of how KCA makes the best out of whatever you've given it. Do you mind if I embed it in the OP? Other than this video, this mod is in dire need of some publicity - I keep finding threads in Addon Request & Support asking for the features of this mod. I think I may actually put it on Spaceport at some point. Would you be interested in making more demonstration videos, e.g. demonstrating an ascent and docking (which with the new Combined Mode should not require any modes/settings to be changed during flight), or deorbiting a VTOL to land on the Mun? Some people prefer moving pictures to my walls of text. I would be very interested in trying to reproduce your problems, as personally I have yet to encounter any framerate issues at all with the new solver during flight. Could you post a description of your setup, including mods installed and your system spec, as well as a craft or two I can reproduce this with? Hah, it's not quite as bad as that. This mod gives you much more freedom in your designs, but you still have constraints to work to - it does not break the laws of (KSP) physics. Also, thanks for posting that quote - it alerted me (via email) to Torminator's edited post.

If it keeps in line with the rest of the instrument panel it will also be self-illuminating.

It's because the stock navball prop includes an annoying holder for the navball, and there is no way of embedding the prop into the instrument panel without that holder protruding.

Some of the bugs I have found in KSP during the development of this project are really infuriatingly simple mistakes on behalf of the developers. I won't rant about them here, though. Also, speaking of augmenting ModuleLandingGear, I think I may have a solution for the rotation problem - give ModuleLandingGear a dummy transform for its wheel, and update the actual wheel's rotation yourself, using a lightweight part module added at load time using a technique similar to the way Module Manager works. I have used a similar technique with success in KCA to augment ReactionWheel, ModuleEngines and ModuleGimbal, and entirely replace ModuleRCS. Also, do you have any idea what causes the glitchy bouncing problem? I'll take that as a compliment. Hah, I might need to post a slightly modified disclaimer before the mod is released.

No, this isn't a photo. This is what you get if you zoom in on the PFD in the cockpit. It's a special shader I've made to emulate the appearance of an LCD. I could easily change it to look more like a CRT if necessary. Don't worry, the performance impact is minimal.

Right, new release, though it's a bit later than I intended, due to work on the Kerbin Mini Shuttle.