Part modules

A few of the modules in the package are actually part modules and go into part.cfg to support the function of IVA components:

JSIExternalCameraSelector

It may often be desirable to provide the user with an option to place a camera elsewhere on the vessel, but then you have to provide a part for it, since cameras require a named transform to work from. If you want to have a lot of cameras, as many people seem to prefer, it would require creating lots of parts with individual models, which feels like kind of a waste. This PartModule permits the user to switch the camera ID between a set of predefined names by right-clicking the camera part itself. The selected IDs will persist.

To work, the module requires the camera object to have a named transform, which either has a child transform you don't care about, or doesn't have any children. If it has any, they will be cruelly twisted and consumed, so beware. That child transform is getting renamed as soon as the vessel loads, and it's orientation and position is forcibly set to that of it's parent transform. Configuration:

• cameraContainer -- Name of the parent transform that has a child transform that will be the actual camera transform.
• cameraIDPrefix -- Defaults to "ExtCam"
• maximum -- Maximum camera ID the user will be permitted, defaults to 8.
• rotateCamera -- Additional rotation vector to be applied to the child transform after it's position and rotation are slaved to that of the parent transform, around X,Y,Z, in degrees. Unity rotates them in reverse order, so remember that first rotation around Z will be applied, then around Y. Using this is only recommended if you have no other option and are forced to use a model that you can't edit for whatever reason -- it is always better to just correctly orient the parent transform if you can.
• translateCamera -- Additional offset vector to be applied to the child transform. Note that it is applied in the local scale, so may need quite a bit of tuning to get right.
• showRay -- Boolean, defaults to true. If it is false, the visibility cone will not be turned on automatically when the camera is picked up.

The generated camera names will have the form <cameraIDPrefix><number>, camera numbering starts with 1, so on the first launch of the vessel the camera will by default be named "ExtCam1" and allow switching all the way up to "ExtCam8". You probably want to have your own name prefix.

In editor, the part with this module enabled will display a light cone indicating the general direction of what it will be seeing, with the default field of view angle of 60 degrees. Selecting the camera ID in the editor can be accomplished through tweakables. Holding down U (or whatever the light toggle button is mapped to) will display the field of view of all cameras at once.

JSITransparentPod

Warning: This module is still highly experimental.

This module will make your pod transparent, i.e. it will be possible to see what's going on inside while you're looking from the outside -- just like with the once-famous plugin by sfr, which has always been known to be temperamental. This module is a complete rewrite from the ground up to make the technique actually work reliably.

The biggest disadvantage this version has is that when looking from inside of any pod, you will not see the inside of any other pod. (It was either that, or various takes on seeing double kerbals floating around your face. Blame Squad for introducing a different coordinate system for IVAs for no discernible reason and then making everything rely on it.) The module strictly speaking requires no configuration:

MODULE
{
    name = JSITransparentPod
}

There are four optional parameters to control it's auxiliary function -- changing shaders on transforms of the pod:

• transparentTransforms -- A '|'-separated list of transforms that need to have their shader changed. This list is empty by default, if you give no transform names, no shader flipping will be performed.
• transparentShaderName -- The shader to substitute. Defaults to "Transparent/Specular".
• opaqueShaderName -- Empty by default. If this is given, instead of restoring the original shaders when the pod needs to go to a non-transparent shader, the given named shader will be used.
• restoreShadersOnIVA -- Defaults to true. If true, shaders changed by transparentTransforms will be returned to original state when the user goes IVA.

The reason for the whole changing-shaders-around circus is the fact that it is impossible (unless someone can figure out a workaround and I have established this someone is probably not me) to show transparent pods while the user is in IVA without unavoidable display artifacts due to inherent KSP limitations. The shader swapping trick allows you to conceal this fact by displaying non-transparent windows while in IVA and transparent windows while out of IVA.

Other caveats:

• Having sfr's original transparent pod module on any objects within your world will cause visual artifacts.
• To prevent some other visual artifacts, a module needs to be added to every pod that has an IVA but is not transparent. This is handled by a ModuleManager patch you can see in JSI/RasterPropMonitor/Plugins/invisible-pods-handling.cfg

A capsule properly designed for transparency must fit these criteria:

• IVA and the outer model should match up strictly, which is apparently not the case for most pods. Props should not poke through the walls. (Unless they're using JSISelectivelyVisibleProp, at least.)
• Props should not contain flat mesh colliders -- such objects when seen with a world-space camera cause Unity to spam error messages and cause a sharp drop in performance.
• Windows must be a transform of their own, so that their transparency can be manipulated.
• They must appear transparent (at least partially, or there's no point) with one shader and opaque with another shader. For example, they can have a texture with an alpha layer on the windows, and use KSP/Diffuse for opaque state while using KSP/Alpha/Translucent for transparent state. You can pick any pair of shaders, or even use one shader for transparent state and multiple others for opaque state, as long as this condition is satisfied, though.
• These windows must remain transparent from the inside regardless of that state. I.e. pod exterior should be a mesh with normals pointed out only, and if any glass texture is desired from the inside, it should be a transparent texture on the internal model that can always be seen through.

It is unfortunate that sfr's original transparent pod does not satisfy these conditions due to having double-sided windows that only exist on pod exterior.