ZRM

Balancing the shuttle was taken care of even before the shuttle was brought into Unity - we're using my analytical thrust balancing plugin KerbCom Avionics (see my signature). Unfortunately for the time being my plugin does not support SRBs, so we're using liquid boosters, which work well enough. The shuttle is very stable using the plugin, during all stages of ascent and orbital manoeuvres, as well as under RCS control. This has all been discussed at length earlier on in the thread.

Exactly. The scipting interface means that changing the units (including the on-screen text saying "FEET", etc.) is a very painless set of small changes to the config file that any user that has ever edited a KSP config file should be right at home with (although it is not in the KSP config file format, the concepts are similar). And don't forget that the NAV mode is all metric. The HDG mode is designed purely for atmospheric flight. You can have units on your displays in furlongs per fortnight, Jebs (the circumference of Jebediah Kerman's head, now in common parlance among KASA engineers due to historical reasons involving his previous career as a crash test dummy), or even radians (for the heading and bank indicators) if you want.

Then you've never seen the instrumentation for a British or North American aircraft? Most of them use a combination of knots, nautical miles, miles, feet per second and feet, with Celsius for temperature and inches of mercury or pounds per square inch for pressure. I personally have yet to see the inside of a metric cockpit, though I would be glad to leave imperial/U.S. units behind.

As has been previously mentioned, this is expected normal behaviour. lpsolve55.dll is a native library. KSP doesn't know this and tries to load it as a .NET DLL and fails. My code then loads it properly later on. You can safely ignore that error message.

I'm sure he intends to fix that. If not, it's easy enough to do yourself. Well, S.I. units are actually what I started with, but helldiver is the one making most of the design decisions, and he wants the imperial/U.S. distance units, so that's what I have set as default. It's very easy to change the units, and even the units labels with very small edits to the config file. Look at some of my most recent posts for an idea of this. This has been discussed, and currently the shuttle will be released with a Modular Fuel System as a requirement, with a stock fuel version in the works. A stock-fuelled version will need to have all of its statistics balanced to work as well as the MFS version. Thanks for the compliments. I'm lucky to be collaborating with such a talented artist. MechJeb sort of works with it, but due to the off-centre thrust vector at the later stages of the launch it can be quite inaccurate. I recommend launching manually (it's not that hard) until I have created the programmable flight computer that can take care of all of this for you after you've written a landing script. I can reliably land the shuttle with its current aerodynamics model (which is subject to change) using the following method: For de-orbiting, I recommend turning on the MechJeb landing prediction indicator, but not actually activating the landing guidance. Then, from LKO (80-100Km), so that you don't re-enter too fast, you want to perform the de-orbit burn opposite where the KSC will be when you reach periapsis so that the landing predicition moves over KSC. I find that it does not have to be exact. It's best to overshoot slightly, then burn off any excess velocity by performing S turns (like the real Space Shuttle) on approach to the runway. In the first stages of re-entry (hyper/supersonic) a 20 degree angle-of-attack (AoA) seems to work well enough (and looks cool) without making the vessel skip back to orbit, then later on at slower speeds you can adjust the AoA to stay on target. You want to touch down at 80m/s (180mph) so that you don't stall, whilst also reaching a low final sink rate. You will need to perfect your glideslope and the timing of your final flare to reach this at the right point, though there is quite a bit of leeway as the brakes on the shuttle let it come to a stop after only 3/4 of the length of the runway. All in all, once you know what you're doing landing the shuttle as it is right now is quite forgiving and reliable, in my experience. Now, that was the semi-realistic and efficient way to fly it. If aerodynamics-induced stress and heat damage were accurately modelled in this game it would also be the only way to fly it. The Kerbal alternative is to simply deorbit late at a steep angle and pull up to circle around the vicinity of KSC at around 3 Km up to bleed off speed until you are slow enough to line up and land. You still need to pull off the flare well to get to the right final sink rate and landing speed. Chances are that this descent profile would not work well with FAR (expect wings to rip off) or Deadly Re-entry (expect everything to blow up). Please note that I have not yet experimented with support for either of those mods. By the way, the shuttle flies well with the above suggestions only if it has the V tail configuration. For some reason one stabiliser is not stable enough right now, resulting in a shuttle that likes looking everywhere but where it's going.

Yes, I've been waiting for the forums to come back online so that I can post a progress update and resume contact with helldiver. Here is a screenshot of the PFD that is likely very close to what will be used for the first release: All of that display is functional, including the indicator labels ("RCS ON", "ENGINES 67%", etc.) and the directional markers on the heading tape and ADI (which include the normal complement of markers as you would find on the navball). A lot of the "display-specific" parts, like the values displayed on the labels and the indicator tapes, are script-powered, as explained in my previous post. None of their functionality is hard-coded into the plugin. Of all the dynamic elements in the display, only the ADI gimbal and heading indicator are unscripted, for the time being. There may be ways to extend their capabilities in the future with scripting. So now I am waiting upon helldiver for more MFD mode designs. This first mode took a long time due to several corrections that had to be made to the way helldiver creates each asset so that it displays correctly without artefacts, as well as changes to the overall design due to usability concerns. I still had to recreate several parts from scratch using his designs as a reference so that they could actually be used in the display. His problems are mostly due to the limitations of Photoshop. Luckily I have Illustrator so that I can easily make the pixel-perfect versions of each asset. The idea for future display modes is that helldiver sends me his draft design, and then I create the final assets to the specifications I require in Illustrator. This should make the process a lot quicker, instead of slow back-and-forth PMs as each asset is corrected. P.S. For the future of the MFD plugin I am thinking of recreating actual displays from real aircraft/spacecraft. First on my list is the newest Space Shuttle electronic PFD: This will be a bit of a challenge due the embedded 3D navball that will need to be rendered, however I have ideas for drawing this efficiently with high quality. P.P.S. Yes, I know the heading indicator on the in-game PFD is missing the indicator notch. That will be added in due course.

I did not think of actually using the actual MFD model, but I guess that would be a handy addition for the plugin - otherwise people would not be able to use the plugin separately without making their own parts for it. Your MFD could be used as a prop in existing cockpits. Thanks for the offer. You don't need to send me the assets at the moment, but when you do, please could you make the MFD shallower than the MFD you previously sent me, so that it is better suited as a prop for placement in stock cockpits? It would then also look more like an LCD display. Slowly but surely, everything is coming together.

Indeed. I can't wait to make the programmable computer plugin just to see what people would come up with. Imagine the auto-optimised launch trajectories, synchronised close proximity launches (with KerbTown for the extra launch pads), formation flying and aerial displays, autonomous space station/base construction, computer-controlled convoys of rovers following your rover, AI-controlled "opponents", etc. Java is a good starting point for beginners, but bearing in mind how similar it is to C#, and that KSP plugins are written in C#, you may want to start with C#. Both languages have thorough documentation and good tutorials available on the internet. Also note that the code you quoted is a combination of YAML, a markup language, and Boo, a Python-inspired .NET language (it runs using the same system as C#, just with different syntax). Python is also supposedly good for beginners, though I am concerned that due to its nature as a dynamic language once you learn Python you may find it difficult to migrate to other, more restrictive (but faster), static languages such as Java, C#, Boo, C, C++ etc. So overall I would recommend Java or C#. That is my intention. The plugin that powers the MFDs would be released separately (perhaps under the moniker "KerbCom Glass"), with helldiver hopefully giving permission (we have not discussed this yet) to release the shuttle MFD graphics as an example MFD set for the plugin release, as well as bundled with the shuttle. Thanks!

Foreword: There's been a lot of screenshots and pretty pictures in the development updates in this thread, but as well as the artwork there's a lot of coding that goes on behind the scenes to make it all work. Now that I have turned the prototype "hardcoded-everything" MFD plugin into something more suitable for release, I figured I would start doing some development update posts to give some insight into some of the new territory this mod is venturing into. This update is about the graphical Multi-Function Displays (MFDs) used by the shuttle, specifically how I manage and abstract the differing layers of responsibility of rendering display components (such as a compass or altimeter) on each display. The key maintainability goal is to keep decisions about data that is specific to a display out of the plugin and strictly within the config file. I have now got a usable scripting interface working for the MFD configuration files, after a long day of head-butting against Unity, Mono and Boo in (eventually successful) attempts to coerce everything into running correctly. This may at first glance not seem very relevant to the short term goals, but it is in fact desperately needed for this project to stay manageable, especially as the number of total different display components increases rapidly, as it will do soon. It saves a lot of time in the long run and cuts down on code bloat and the need to patch the plugin for any UI tweaks. The scripting interface means that I do not have to code an instrument renderer class for each possible flight statistic you would want to display (e.g. KIAS, EAS, TAS, and that's just for airspeed). For all of the prototype screenshots that have been posted so far the specific variables being sent to each instrument (e.g. airspeed, altitude etc.) were hardcoded into the application. If I let the project continue in this way it would result in a lot of redundant code that is specific to a particular use case, which is a headache to maintain and generally Bad software engineering. The introduction of a scripting interface means that the specification of the data to display is defined via code snippets in the configuration file, abstracting display-specific data manipulation away from the plugin itself1. An example best illustrates the problem and the solution. I previously required classes in my code dedicated to each type of vertical tape instrument (e.g. altimeter, airspeed indicator, vertical speed indicator etc.), each specifying the slight difference that determines the value that is shown on the tape. You would then specify the individual class by name in the list of instruments in the config file (which, by the way, is written in YAML): # An instance of the altitude tape class. This only shows the current altitude, in metres only. - altitude_tape: # these properties determine the location and appearance of the tape instrument top_left: [363, 114] background_tex: Altitude_tape_border tape_tex: Altitude_tape mask_tex: Altitude_tape_border_mask char_atlas_tex: djvsm16 number_colour: [1, 1, 1] tape_number_top_right: [59, -7] needle_tip: [74, 141] interval: 50 # An instance of the speed tape class. This only shows the current speed, in metres per second only. - speed_tape: top_left: [0, 114] background_tex: Speed_tape_border tape_tex: Speed_tape mask_tex: Speed_tape_mask char_atlas_tex: djvsm16 number_colour: [1, 1, 1] tape_number_top_right: [59, -7] needle_tip: [74, 141] interval: 10 Similarly, I would have had to come up with code for every possible dynamic readout label (e.g. altitude, airspeed, G-force, main throttle, periapsis, apoapsis, ETA to periapsis, etc.), which would be inefficient and difficult to maintain and limit what can be shown on a display to what I can think of in advance. The new system solves all of these problems. For example, vertical scrolling tapes are all covered by one class, which uses dynamically compiled script snippets to control the values it displays. Here's the config for the same two tapes from above rewritten using the new system: # An instance of a generic vertical tape, with its behaviour set by script snippets to display the current altitude in feet. - vertical_tape: top_left: [363, 114] background_tex: Altitude_tape_border tape_tex: Altitude_tape mask_tex: Altitude_tape_border_mask char_atlas_tex: djvsm16 number_colour: [1, 1, 1] tape_number_top_right: [59, -7] needle_tip: [74, 141] # local_defs - persistent variables/definitions used by update or value # | is YAML code indicating a multi-line text block. It is not part of the script. local_defs: | static final FEET = 3.2808399f unit = FEET # value - a simple way to specify the expression value displayed by the tape - in this case # the vessel altitude in feet, pulled straight from the KSP API via FlightGlobals. value: FlightGlobals.ship_altitude * unit interval: 50 # Another tape, controlled by the same class as above, but configured with different script # snippets so that it displays the current speed in nautical miles per second in the current # UI speed mode (Orbital, Surface, or Target). - vertical_tape: top_left: [0, 114] background_tex: Speed_tape_border tape_tex: Speed_tape mask_tex: Speed_tape_mask char_atlas_tex: djvsm16 number_colour: [1, 1, 1] tape_number_top_right: [59, -7] needle_tip: [74, 141] local_defs: | static final knots = 1.94384449f unit = knots # update - for more complex computation requiring more than just a single expression # you can use this callback to change rendering properties every frame. These so far # include the position on the tape (value) as well as the increment between tick marks (interval). update: | match FlightUIController.speedDisplayMode: case FlightUIController.SpeedDisplayModes.Orbit: value = FlightGlobals.ship_obtSpeed * unit case FlightUIController.SpeedDisplayModes.Surface: value = FlightGlobals.ship_srfSpeed * unit case FlightUIController.SpeedDisplayModes.Target: value = FlightGlobals.ship_tgtSpeed * unit interval: 10 These config entries now include code snippets (in the optional properties local_defs, update and value_expr) that the plugin compiles to machine code2 when the game loads and runs in flight to determine the behaviour of each instrument. As you can see, this decouples the possible values that are shown on display components from the component renderering code itself, which cuts down on code I need to write, and allows other modders (once this is released) to come up with their own ways of displaying any data they like using the existing components. You could for example use this, in the case of the new vertical_tape components, to dynamically change the tape increment based on the current rate of change of the value so that the tape never moves too fast to read. Similarly other component properties can be customised by scripting, such as changing the ADI ground colours to shades of purple when you fly to Eve. Of course, this scripting interface is just scratching the tip of the iceberg. All code snippets are written in Boo, a fully-fledged .NET language, and are given full access to just the KSP API. The natural extension of this project would be to create a generic programmable flight computer that runs Boo scripts. As an idea of how powerful this would be, most features from existing mods would be automatically made accessible to scripts, such as the thrust balancing features of my mod KerbCom Avionics (many of which are not controllable via the KCA GUI for usability reasons), the fuel balancing features of TAC, and control over the servos of Infernal Robotics. Then anyone could use the combined features of KSP and the mods they have installed to write a personalised control script for their crafts, such as a flight guidance computer for a shuttle. Depending on how much interest there is, once the project is released I might do more posts explaining the other aspects of the project, such as the shader compilation and material management plugin and the upcoming acyclic attachment node plugin to be used on the shuttle EFT attachment points. Sidenote: Boo has extensive support for metaprogramming that allows you to create new language variants within Boo (known as Domain Specific Languages). As an example, it is very likely that nearly all of the KOS scripting language could be reimplemented as macros in Boo, with the additional bonus of giving access to the entire KSP API. P.P.S. Please note that all scripts using the system run just as fast as a plugin would - each script is compiled in memory when the script is first used (known as Just In Time compilation). P.S. Security is not a concern, as .NET provides "sandboxes" for untrusted code (such as user-made scripts) to run in, restricting access to things like the filesystem or the internet. [1] As the influential computer scientist Dr. David Wheeler (inventor of the infamous goto statement, amongst other things) succinctly observed - "All problems in computer science can be solved by another level of indirection.". [2] Well, not actually machine code, but Common Intermediate Language - .NET bytecode, the same thing C# compiles to.

That is a possibility, but it would require quite a few changes to the overall structure of the GUI so that it all works well. It's on my to-do list. I don't think that is a solution to a legitimate problem. I do not believe many people would make the mistake you're suggesting. Anyone who does mistake one mod for the other will soon realise they're in error due to the vast differences between the two mods. Besides, the Com in KerbCom stands for any of "Computers", "Computing" or "Company", but certainly not "Communications", so KerbComm is not a possibility. It's also probably not a good idea to change the name of a mod after it has been around for over 4 months, since that could cause even more confusion, especially concerning any search engine queries. Looking forward to what? The SRB support? If so you will have to wait a while, since I probably won't have any time to work on that properly until December at the earliest, due to RL commitments. You're welcome. 1) Engine availability/activation is not the problem. If an engine exists, KCA knows whether it can use it, and if it can use it, whether giving it a non-zero throttle helps to achieve the overall goals. If KCA keeps engines at a low throttle that means that any higher overall thrust would be impossible since it would cause unwanted rotation. There must be some underlying problem with either your craft's layout, the gimbal range of your engines or the total strength of your reaction wheels. In a mainly stacked narrow vessel the likely culprit is that the vessel does not have enough roll authority, in which case you need to improve that either with more RCS ports, more reaction wheels, engines with better gimbal ranges (the stock engines have woefully small gimbal ranges compared to real life) or the addition of radially-attached perpendicular engines. Also, since active (firing) SRBs are unsupported, you need to make sure that there is not a point where SRBs are active on the KCA-controlled vessel, as it will assume they can be used like normal engines. Really I should change this so that SRBs are specifically ignored by KCA for the time being so that sepratrons do not cause ill effects when activated on a KCA controlled vessel (note that sepratrons only activated to move spent stages away do not fall into this category). You may want to try your design wihout the SRBs and see if it makes a difference. 2) Thank you very much for this feedback. Multi-craft/Multi-avionics behaviour is the least developed part of the plugin, and the behaviour is not ideal, as you've highlighted. The current implementation was designed purely as a stopgap. Improving this is on my to-do list. Edit: Great, glad to hear it's working well for you. I'm also pleased that it works alright with KAS, as I have yet to test that.

Looks like you've found a bug (or two). Unless I can reproduce it it would be difficult for me to figure out exactly what's wrong. Any chance that I can have a copy of your setup? UNBOUNDED in the fuel optimisation stage (which is what all that means) probably implies that the fuel objective function somehow has at least one infinite coefficient. So it would be a case of adding Debug.Log statements to figure out what's dividing by zero. The fuel optimisation stage is the last stage, after the torque optimisation, thrust optimisation and monopropellant optimisation, so whatever is breaking it can't be breaking the other stages, which would suggest that it's calculating the fuel efficiency of the engines incorrectly. Edit: Regarding SRBs, that is something I will only look into after the first Kerbin Mini Shuttle release due to the considerable amount of work involved, as several parts of the solving process will need to be overhauled since they often rely on zero thrust being feasible. Yep. Not much I can do about that without trying to fix MechJeb. Auto-docking doesn't seem to work (for me) very well anyway. It should be doing that already. If it isn't either it can't, because using the NERVAs exclusively would not be balanced, or it's somehow bugged (and might be related to Tiberion's problem).

Hmm, those proportions look suspect. Are you sure that's made from measurements, and not just fan-art?

It will probably be similar to that, but with the UI overlaid on the video feed, and probably with some additional numerical readouts.

No, it just happens to be that the rotation is about the crosshair - if you move the crosshair the problem won't be fixed, and the rotation will still be about the cockpit Z axis. It's a stupid hard-coded limitation within InternalNavball. Unfortunately helldiver had finished up his models and texturing before anyone had checked whether the Kerbals could see over the dash - he thought the Kerbals were quite a bit taller than they actually are. But it's not going to be too bad - the double click view need not obscure the instrumentation - it can just move the view up to where helldiver thought eye level was originally going to be. Also, if we get the ILS working properly you would be able to land even in (so far non-existent) fog. Uh, no, I was talking about the picture-in picture Kerbal-cams. I have no control over the first person cameras. IMO the best scenario to have in KSP is where default view gives you a good view of what's in front, and you can double click to get a better view of instruments or pop up a 2D window of an instrument like in FSX (which is very doable). Not necessarily critical, if you have the right instrumentation, but yes, it's very useful. Don't forget that the cockpit will eventually be including an in-cockpit video feed from the docking port. Here's a first attempt at a high visibility view. Remember that this view can be zoomed and rotated just like Kerbal POVs. Also please note that the PFD on the far left is a functional prototype, and the other displays including the HUD are placeholder images (thanks for those helldiver).

The remaining problems are that the markers orient themselves by the central crosshair, so they seem to rotate around it, which is especially noticeable when they cross over the crosshair, and also the retrograde target marker is not visible. Ideally I would like to implement an improved navball module to fix these problems.

I'm sorry, I really can't help but take more and more screenshots of this wonderful cockpit. (Also please, again, ignore the MFD panels). Notice the reduced contrast on the windows and MFDs due to the lights being on. This is affected mainly by the specular exponent. I think I will need to increase it in order to reduce the low contrast effect a bit. By the way the glass is powered by a custom shader, since no stock shader provides transparency, an emissive component and a specular component at the same time.

Uh, I don't see what you see I mean with analog_gauges. I didn't mention it AFAIK. Could you elaborate?

I didn't think Universe Replacer could do anything to meshes. Fixing the problem shown requires editing the UV set, because each shoulder probably currently shares the same UV space. You can't fix that with a texture.

Yep, pure luck with the poses. Only a static VSI would make sense being non-linear. That is what I was referring to. Have a look at any electronic static VSI for an example. Moving tapes have to be linear, but their intervals change depending on the current situation. Just to clarify, you are going to be sending me a new set of textures (with each component in a separate PSD) for the PFD with the correct masks, right? I'm sort of treading water here, working on finishing up the details of the other parts (such as the cameras and lighting).

You'd be surpised. It's amazing how much is possible via plugins. Replacing textures is possible, and I think editing meshes at runtime is also doable. Of course it may turn out that this is not possible for animated objects due to potential limitations in Unity. Edit: Here's a shot with the latest lighting. Please ignore the apparent dials in both the MFDs and the front windows.

Uh, not just one actual light, 16 unshadowed spotlights to be precise. I can probably get away with half that number or less. I currently have 4 lights per ceiling light panel. One or two per panel may suffice. I added 4 lights because previously I was hopeful that I could get shadows enabled and do a high quality screenshot or two, but unfortunately Unity doesn't support shadowing on anything other than directional lights in a forward renderer, which is mad. That is very strange, though for all I know this is the case in other IVA cockpits. Yet another KSP bug.

Thanks for that. I've updated the OP.

Bill wishes he didn't have a window seat. Also, now with interior lighting. Edit: Since that screenshot I have now improved the colour temperature of the lighting to match the actual lights.

Lobal's a bit too happy with the view (well, either that or deranged). Matcott doesn't feel the same way. Perhaps he's scared of Lobal.

The point is that after you see these internals, with the electronic glass cockpit, you will be using them nearly all the time, as it will hopefully be more informative than the navball and the map view for most situations. If we release early that would just slow down the development of the final features, as we would then have to spend time on supporting the release. Besides, neither I nor Helldiver like releasing something not quite done. Please can everyone stop asking us to release this early. We will release it in due course, when it's ready, not a moment before. Edit: By "everyone", I really mean the few people that have asked this. Most of you have been great support, thanks for that.