Skip to content

Part modules

Jump to bottom
MOARdV edited this page Sep 26, 2015 · 28 revisions

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 (also X,Y,Z) 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.

JSIRadar

This module adds a "radar" capability to a craft. The radar is able to automatically target something (vessel, asteroids, optionally debris, but not planets/moons) that is within range and within the radar's field of view. Multiple configuration options are available to change the behavior of the radar, such as requiring the target to remain in the radar's range and field of view. When added to a part with a docking node, the radar configures itself as a docking radar, searching for targets whichever direction the docking port faces.

In the VAB and in flight, the radar can be switched on or off, and the radar can be set to ignore debris or target debris. In the VAB, there are also action group options to turn the radar on, turn it off, or toggle it.

  • maxRange -- The maximum range, in kilometers, that the radar can detect objects. Defaults to 200km.
  • scanAngle -- The field of view of the radar, in degrees. Any target within this angle of the center of the cone (defined below) may be detected, if it's in range. Defaults to 30°.
  • resourceAmount, resourceName -- The amount of resources consumed per second, plus the resource type. It defaults to 0 and "ElectricCharge", but someone could make a monopropellant-fueled radar if they really wanted to...
  • radarTransform -- The optional name of a transform in the part that should be used as the radar's transmitter. If omitted, the transmitter is positioned as described below, under Radar Behavior.
  • targetDockingPorts -- When set to true, when the target is close, the radar will select the nearest docking port (if one exists); if the radar is on a part that has a docking port, it will target the nearest compatible docking port. Defaults to false.
  • restrictTracking -- When set to true, the radar will unselect a target if the target moves outside of the tracking cone. Use caution with this feature: if there are multiple radars using this feature and the target moves outside the tracking cone of any of those radars, it will be unselected. Defaults to false.
  • trackWhileOff -- When set to false, the target will be cleared when the radar is switched off. As with restrictTracking, use caution when applying this feature to multiple radars. Defaults to true.
  • targetDebris -- When set to true, the radar will target debris, not just vessels. Defaults to false. This option can be changed in the VAB and in flight. Defaults to false.
  • radarEnabled -- Is the radar switched on? Can be toggled in the VAB, in flight, and using action groups.

Radar Behavior

The radar searches for targets within a cone defined by the scanAngle and maxRange parameters. The direction of this cone depends on the following: if radarTransform is defined and exists on the part, the radar uses the "up" direction of radarTransform. If the radar is on a part that has one or more docking nodes, and there is no defined radarTransform, the radar uses the "forward" direction of the first docking node (which corresponds to the direction the docking port faces. If radarTransform is undefined (or not found), and the radar is not on a part with a docking node, the "forward" direction of the part's root transform is used (the front of a spaceplane, the top of a rocket).

When the radar is switched on, if there is no target currently being tracked, the radar will look for the nearest target within its range and field of view. If it finds something, it will target it. If there are multiple options, it selects the nearest one.

While the radar is on, it will consume resources (if configured to do so). If it runs out of resources, it will stop scanning. If trackWhileOff is false and it runs out of resources, the vessel will clear the current target (NOTE: this rule applies even if the target was manually selected, or a celestial body that the radar would not normally track).

While the radar is on, if a vessel is currently being tracked and targetDockingPorts is true, the radar will attempt to target docking ports when the target is close enough. The radar will select the nearest docking port. If the radar is on a part that has a docking port, it will select the nearest compatible docking port, instead.

If the radar is switched off while a target is selected and trackWhileOff is false, the target will be cleared.

If restrictTracking is true, the target must remain within the cone of the radar, and within range, in order to keep tracking it. This rule applies even to targets that the radar wouldn't normally track.

This radar does not model real-world sensor behaviors (detecting larger targets at longer distances), since I am trying to keep the computational overhead to a minimum.

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 and one parameter to help lower-performance computers:

  • 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.
  • disableLoadingInEditor -- Defaults to false. If true, pod transparency is disabled in the VAB and SPH. Note that this can lead to odd looking parts in the editor, so it should not be used unless it provides a significant performance improvement.
  • transparentPodSetting -- Defaults to 'ON'. Other valid options are 'OFF' and 'AUTO'. Controls the behavior of transparent pods in the editor and during flight; can be changed in the editor and in flight by right-clicking the part.
  • distanceToCameraThreshold -- Defaults to 100. Determines the distance from the camera to an inactive vessel at which point RPM stops drawing the IVA.

The last three settings are performance tuning options. disableLoadingInEditor is a big-hammer approach that outright disables the transparency feature in the VAB (or SPH) to help computers that are having a difficult time rendering transparent pods. It has to be set per-pod, although there is the Module Manager patch JSI/RPMPodPatches/DisableTransparencyInEditor.cfg.noload can be used to automatically apply the setting to every pod - simply remove the ".noload" from the end of the name.

transparentPodSetting is a three-way option that can be changed in-game to adjust behavior of transparent pods. When set to 'ON' (the default), transparent pods automatically render their IVA any time they are closer than the distance in distanceToCameraThreshold (in meters). When the pod setting is 'AUTO', transparent pods are shown whenever the mouse hovers over the pod, or when the pod is the reference part of the current craft. When set to 'OFF', transparent pods are not rendered. These options apply per-part, so you can select certain parts to always render (like high-visibility cupolas), while other parts can be set to 'AUTO' or 'OFF' as you see fit.

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.
  • The transparentTransforms field needs to be specified, or the windows will not properly switch to opaque if the user turns off transparency via the right-click menu.

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.

Clone this wiki locally