Background handlers

Background handlers are very much like Page handlers, but instead of a batch of text, they produce backgrounds for pages:

		PAGE
		{
			button = ThatButtonTransform
			text = some text.
			BACKGROUNDHANDLER
			{
				name = YourModuleName
				method = TheMethodToCall
			}
		}

The method in question is passed the RenderTexture of the screen as it's first parameter, the value of the monitor's cameraAspect parameter as the second (float), and must return a bool value. It can then draw on that texture, with whatever text is defined for the page being printed over the results afterwards. Upon successful completion it must return true. If it returns false, the page will be cleared to emptyColor. Whether it returns true or false has no bearing on what will get printed.

Notice that this happens before any matrix operations on the RenderTexture are performed, so it's the author's responsibility to GL.PushMatrix, GL.PopMatrix and otherwise set it up for whatever they plan to draw on it.

The same optional parameters as for Page Handlers regarding pageActiveMethod and buttonClickMethod, getHandlerReferencesMethod as well as the multiHandler are also available. Notice that one page can have both a page handler and a background handler, and in case of a buttonClickMethod and pageActiveMethod, both handlers will receive the method call, unless you pointed those parameters to the same method on the same instance of your module. Notice also that while the same plugin can be both a page handler and a background handler, two separate copies will be loaded in the same page unless the multiHandler option is used.

There is one extra optional parameter that only makes sense for background handlers: showNoSignal. If this parameter is present in the background handler definition block, in cases where the background handler returns false, the screen will be cleared to the no signal texture, rather than with the blanking color, which is the default.

Included background handlers

JSIHeadsUpDisplay

This background handler is intended to represent a 2D type flight display, such as what one might use for a heads-up display in an aircraft, as opposed to the more space-oriented navball. It includes a number of configurable features that can make it useful for far more than just a HUD / PFD.

In particular a set of configurable vertical bars are supported. In a HUD, they could be used to display altitude and vertical speed. However, they can be used without the horizon texture and heading texture, so that one could have scrolling graphs or gauges as the background of any page.

			BACKGROUNDHANDLER
			{
				name = JSIHeadsUpDisplay
				method = RenderHUD
				...configuration options go here.
			}

Configuration Options:

• backgroundColor -- The color of the background of this page, if no camera is specified.

• cameraTransform -- The name of an optional camera to use to draw the background of this page. Using a camera with transparent horizon textures allows for a HUD to be rendered on any RPM monitor, regardless of whether it's actually a transparent screen by itself.

• hudFov -- The field of view of the camera, in degrees.

• horizonTexture -- The name of the texture to use for rendering the HUD's artificial horizon. If no name is specified, the horizon is not drawn. For a 360 degree texture, the 0 degree pitch position is the middle of the texture (vertically). +90 half way between the center and the top of the image, and -90 is half way between the center and the bottom of the image. For a 180 degree texture, 0 is again in the middle, +90 is at the top, and -90 is at the bottom.

• horizonSize -- <width>, <height> The size of the area where the horizon texture should be drawn, in pixels. The horizon is drawn centered in the display.

• horizonTextureSize -- <width>, <height> The portion of the horizon texture (in texels) that should be drawn within the horizon area when the craft is wings level. For instance, if the horizon texture is 256 texels wide, and horizonTextureWidth is 128, then the middle 128 texels of the texture (from column 64 to 192) will be visible when the craft has a roll of 0. The area outside the horizonTextureWidth region will only be visible when the craft is rolled to the side.

• use360horizon -- Defaults to true. Indicates whether the horizonTexture is a 360 degree pitch texture (when true) or a 180 degree pitch texture (when false). The horizon texture clamps, so a 180 degree texture will show nothing "above" the 90 degree pitch mark, and nothing "below" the -90 degree pitch mark.

• headingBar -- The name of the texture to use for rendering the HUD's horizontal heading strip. If omitted, no heading strip is drawn.

• headingBarPosition -- <xPosition>, <yPosition>, <width>, <height> the X and Y coordinates (measured where from the top-left corner of the display) and the width and height of the heading bar, all measured in pixels.

• headingBarWidth -- The portion of the heading bar texture, in texels, that will be visible within the aforementioned rectangle.

Vertical Bar Gauges: There are two vertical bar gauges. The variables listed below control the first gauge. Gauge 2's configuration values have a '2' instead of '1' (ie "vertBar2Texture").

• vertBar1Texture -- The name of the texture to use for rendering a vertical bar gauge on the HUD.

• vertBar1Position -- <xPosition>, <yPosition>, <width>, <height> The position and size of the vertical bar gauge, in pixels.

• vertBar1Limit -- <minimum>,<maximum> The minimum and maximum values of the variable used for vertical bar 1. Results outside of this range are clamped to the limits.

• vertBar1TextureLimit -- <minValuePosition>, <maxValuePosition> The pixel locations (measured from the top of the texture) that correspond to the minimum and maximum values of the vertical bar (the values in vertBar1Limit, in other words).

• vertBar1TextureSize -- The height of the visible portion of the vertical bar texture, in texture pixels. The current value is always centered in the vertical bar.

• vertBar1Variable -- The variable used to control this graph. See Defined Variables.

• vertBar1UseLog10 -- Defaults to true. When this Boolean is set to "true", the vertBar1Variable and vertBar1Limit are rescaled as follows: for values between -1 and +1, the value is unchanged. For values outside that range, the value becomes (1 + log10(abs(value))) * sign(value). For instance, 10.0 becomes 2, and -100.0 becomes -3. This allows for the creation of gauges that are less precise the farther away from 0 the value becomes. When using one of the variables that end in "LOG10", set it to false.

• staticOverlay -- An optional overlay texture that is drawn after everything else has been drawn.

Vertical Bar Configuration

The vertical bars have a number of configuration parameters, all of which are required for the vertical bars to work well. While they are described above, here is an example to help illustrate how they're used:

Let's say we want a radar altimeter that tells us how high above the surface we are. We don't really care about tracking altitude above 10km, and we know we're never going to be below ground. We have a texture, /myHUD/radarAltTexture, that is 128 pixels wide and 1024 pixels high. It has a log10 scale (as described above under vertBar1UseLog10), with the 0 mark at (0, 878) and the 10000 mark at (0, 146). We want this on the left side of the screen. We set up the basic parameters as so:

vertBar1Texture = /myHUD/radarAltTexture
vertBar1UseLog10 = true
vertBar1Variable = RADARALTOCEAN
vertBar1Limit = 0, 10000
vertBar1Position = 0,0,128,640

Since the 0 mark is at y=878 and the 10000 mark is at y=146 in the texture, we add

vertBar1TextureLimit = 878,146

We decide we want 256 pixels of the texture (about 1/4 of its height) to be visible at any given time, so we finally add

vertBar1TextureSize = 256

Vertical bar textures clamp (that is, they do not wrap around from top to bottom), so it is safe to have very small top and bottom margins.

JSIOrbitDisplay

The JSIOrbitDisplay background handler draws a representation of the current vessel's orbit, along with circles marking the planet / moon / sun that the vessel is orbiting (and the extent of that body's atmosphere, if applicable). MapView icons for the vessel, Ap, Pe, AN, DN, and maneuver node are drawn on the orbit.

If a vessel in the same SoI is targeted, the target vessel's orbit is drawn, along with the target's position and its Ap and Pe. If a maneuver is planned, the resulting orbit is drawn, as well.

The display rescales and moves each update as needed to keep the current vessel's orbit on screen.

			BACKGROUNDHANDLER
			{
				name = JSIOrbitDisplay
				method = RenderOrbit
				...configuration options go here.
			}

• backgroundColor -- The color that the screen is cleared to prior to rendering.
• iconColorSelf -- The color used to render the current vessel's icon on the display.
• orbitColorSelf -- The color of the current vessel's orbit.
• iconColorTarget -- The color of the targeted vessel, if applicable.
• iconColorShadow -- The color of icon drop shadows.
• iconColorAP -- The color of the apoapsis icon on the current vessel's orbit.
• iconColorPE -- The color of the periapsis icon on the current vessel's orbit.
• iconColorClosestApproach -- The color of the tick marks denoting the ship and target vessel's position at closest approach.
• orbitColorNextNode -- The color of the orbit that will be in effect after executing the next maneuver node, if applicable.
• orbitDisplayPosition -- <left>, <top>, <width>, <height> The region of the screen that JSIOrbitDisplay will draw to. Using less than the full area of the screen allows for header and/or footer text to render without the text hiding parts of the orbit display. All values are in pixels.
• iconPixelSize -- The size, in pixels, of the various orbital icons.
• iconShadowShift -- The offset of the icon shadows.
• orbitPoints -- The number of subdivisions used to render the various circles, ellipses, and hyperbolae on the display.

JSIPrimaryFlightDisplay

This background handler might be used to construct a Primary Flight Display, which is mostly a flat representation of a stock-like navball with extra bells and whistles. This is accomplished by placing a real model into the scene and taking pictures of it with a camera, which involved far more dirty hacks than I would like, but looks very neat.

			BACKGROUNDHANDLER
			{
				name = JSIPrimaryFlightDisplay
				method = RenderPFD
				buttonClickMethod = ButtonProcessor
				...configuration options go here.
			}

Configuration options:

• speedModeButton -- Number of globalButton pressing which will switch speed display mode, which affects what prograde/retrograde markers actually designate. Defaults to 4. The effect is the same as clicking the speed indicator in normal GUI or clicking the InternalSpeedDisplay prop, so it's not exactly required -- if you don't wish to use it, set this value to -1 or omit the "buttonClickMethod" option.
• drawingLayer -- There is considerable confusion about which Unity object layers are available to safely use in KSP for a purpose like this. Apparently, 17 is unoccupied, so this is the default. Altering it to something else can produce amusing results or actually be an improvement.
• horizonTexture -- The texture URL for the actual navball. Required parameter.
• navBallModel -- The model URL for the actual navball. Required parameter. You want it to be mapped in such a way that the point marking 0,0,0 on the ball is the one you see if you look from a camera positioned in Z+ direction. You also want it to have a radius of 0.5 units, but how exactly to map a texture is entirely up to you.
• ballIsEmissive -- Boolean, defaults to false. In the default case, the ball will be rendered using KSP/Unlit shader, in case this variable is true, KSP/Emissive/Diffuse will be used instead and the texture you supply will be used for both texture layers. Unlit looks slightly better, but Emissive/Diffuse is more resilient to the ball catching IVA spotlights.
• staticOverlay -- The texture URL for static overlay elements of the navball assembly -- the 'plane' in the middle and other things. Will be mapped onto a generated square 2x2 units above the center of the navball.
• backgroundColor -- The background color of the screen. Defaults to black, but if you want a clear screen you might want to try 0,0,0,0 instead.
• ballOpacity -- The opacity of the ball image. Defaults to 0.8, 1 being the highest.
• ballColor -- Tint color for the ball image, defaults to white.
• markerScale -- Size of individual markers in units, or rather, distance from the center to the edge. Defaults to 0.1, i.e. 1/10th of the ball's diameter.
• progradeColor, maneuverColor, targetColor, normalColor, radialColor, dockingColor -- Colors of the respective markers. "Docking" is the target dock orientation marker. Since marker alpha color is used to enable ghosting, alpha in these colors will be ignored.
• headingBar -- Texture URL of the heading bar, i.e. compass. You want it to be a long, thin horizontal ribbon that loops, starts at 0 degrees and covers the entire 360.
• headingBarPosition -- x,y,width,height of the heading bar, in units.
• headingSpan -- How much of the heading texture should be visible on the heading bar at any given time. Defaults to 0.25.
• headingAboveOverlay -- If set to true, heading bar will be drawn above the overlay texture, otherwise below.
• cameraSpan -- How much of the entire assembly the camera will see. Defaults to 1, i.e. one unit up from zero and one unit down.
• cameraShift -- How far offset from the center of the ball the camera should be, a 2-dimensional vector. Moving the camera to -1,0 will mean the assembly shifts half of the screen's height to the right.

Ooof, I'm not touching quaternions for at least a month after this one.

JSISCANsatRPM

This is a case of a background handler that interoperates with an alien plugin that I neither wrote nor include in the package. This background handler will access the maps collected by the SCANsat mapping plugin and display them, marking them up with icons denoting things of interest. Doing that necessitates directly accessing the SCANsat DLL, without which this module will not load. If you set up a monitor page to use it, and SCANsat is not installed, the monitor will still work, you just won't have anything on the background on the particular page that calls it.

Caveats:

• This is a separate plugin which needs to be loaded at a specific point in plugin loading order to work -- after SCANsat has been loaded and after RasterPropMonitor proper has been loaded. Since KSP loads plugins in alphabetical order of GameData directories, it needs to be in GameData\SCANsatRPM -- please keep it there. Word on the street is, in 0.23 this will be less of a problem and I will be able to relocate it back to GameData\JSI to keep it all in one place, but that is still a ways off.

• SCANsat map drawing routine assumes that pixels are square, i.e. that if your monitor texture is 512x256, the monitor is twice as wide as it is tall when in the IVA itself. Plan accordingly. While it is possible to correct for this during rendering in theory, it turned out to be easier to adjust the screen texture size instead.

• Map zoom, drawing mode and color will persist, however, due to peculiarities of SCANsat internals, color/grayscale will affect every map drawn with SCANsat anywhere while the vessel with this module is active, i.e. on the GUI, or on any other monitor.

• This module makes use of globalButtons functionality, and is not particularly fun without it, so it is recommended to put it in a monitor that has at least four such buttons.

    		BACKGROUNDHANDLER
    		{
    			name = JSISCANsatRPM
    			method = MapRenderer
    			buttonClickMethod = ButtonProcessor
    			pageActiveMethod = PageActive
    			...configuration options go here.
    		}
  

Configuration options:

• buttonUp -- Number of the globalButton that will zoom the map out.
• buttonDown -- Number of the globalButton that will zoom the map in.
• buttonEnter -- Number of the globalButton that will switch between relief, slope and biome map drawing modes.
• buttonEsc -- Number of the globalButton that will switch between color and grayscale map drawing modes.
• buttonHome -- Number of the globalButton that will switch between showing and not showing trails and orbits.
• maxZoom -- Maximum zoom level. The first zoom level will make SCANsat fit the map width, rather than height to screen. To adjust for this if you don't have a 2x1 screen, you can use the zoomModifier parameter.
• zoomModifier -- You want to adjust this value so that the lowest zoom level does not wrap the map vertically, it defaults to 1.5, but that's what it was for the testing screen, yours is probably different. You want to do it because otherwise, orbits may not get drawn correctly.
• iconPixelSize -- The icons will be this size in pixels when drawn onto the screen. The module uses stock map icons, which are square.
• iconShadowShift -- Defaults to 1,1. Icons will have drop shadows drawn at the position offset by this number of pixels.
• redrawEdge -- SCANsat takes quite a while to redraw the map and drops the framerate quite a lot while it's in progress. (The computations involved are massive, and while there are faster methods to assemble a texture in memory pixel-by-pixel in Unity, they're tremendously difficult to use.) To do it less often, the plugin will only redraw the map itself when the marker denoting the active ship moves sufficiently far to the edge of the screen to warrant it. This value controls how far exactly, and defaults to 0.8, i.e. 80% counted from the opposite edge. This calculation pretends the screen is square, so on non-square monitors, this will be less than 80% of the width of the screen.
• iconColorSelf -- Color of the ship icon.
• iconColorTarget -- Color of the icon denoting the target vessel. This icon will not be drawn if there is no target or the target is not a vessel. (KSP does not natively have any provision to target a spot on the ground no matter what MechJeb might want you to believe.)
• iconColorUnvisitedAnomaly -- Color of anomalies that have not been detail scanned yet.
• iconColorVisitedAnomaly -- Color of anomalies that have been detail scanned.
• iconColorShadow -- Color of the icon shadows.
• iconColorAP, iconColorPE -- Color of apoapsis and periapsis icons on all orbits, respectively.
• iconColorANDN -- Color of the icons for ascending and descending nodes.
• iconColorNode -- Color of the icon of the maneuver node and projected post-node orbit.
• orbitPoints -- The module will attempt to draw the orbit of the vessel and the target vessel (if any) for the next orbital period. The orbits will be drawn with the same color as the icons of the vessel and the target respectively. This parameter sets the resolution of the line, i.e. how many individual points will be used to calculate it -- try to set the lowest you think looks good. Setting this to 0 will turn off the drawing of orbits.

Positioning the scale bar

The module can display the scale of the map in kilometers using the scale bar, which requires two textures -- one for a horizontal bar, which will be resized to fit the appropriate number of meters on the map, and another to display a label saying how long the bar is. (There is, unfortunately, no opportunity to report this to the monitor itself, so it has to be done this way.)

• scaleBar -- Texture for the scale bar itself. 4 pixels from every edge will not be scaled when stretching the bar.
• scaleLabels -- Texture for the scale labels. Labels must be arranged on it vertically in descending order and have the same size.
• scaleLevels -- A comma-separated list of values in meters corresponding to each label.
• scaleBarPosition -- x,y of the bottom left corner of the bar, in pixels, from the bottom left corner of the screen.
• scaleBarSizeLimit -- Every time the scale bar is to be drawn, the length it would take in pixels is computed and checked against this limit. If it is higher than this limit, the next highest value in scaleLevels will be used.

The labels are always displayed immediately to the right of the bar itself, the height of the bar on screen is equal to the height of the label. The height of an individual label is computed based on their number and the height of the texture containing them.

Trails

The map module can draw trails depicting the path the vessel actually took. Trails are time rather than space dependent and they will not persist.

• trailLimit -- Number of trail points to remember, defaults to 100. If you do not want to show trails, set it to 0.
• trailColor -- Color of the trail line.
• trailPointEvery -- Number of seconds that elapse between trail points. Defaults to 30.

Map markup

JSISCANsatRPM supports marking up the map with lines defined as a chain of longitude/latitude points on the sphere, which lets you draw airstrip approach "funnels" and otherwise draw on the map itself. The lines are drawn exactly like the orbits and trails are, i.e. with vectors.

A markup line is defined using a top-level config section "JSISCANSATVECTORMARK", which needs to be in it's own .cfg file. The file can be located anywhere at all, all markup sections defined anywhere in any file within GameData will be drawn. (Unfortunately that means they will only refresh if you reload the GameDatabase, which somewhat complicates editing.) Each section draws exactly one line, from start point to end, i.e. it draws a line between each consecutive pair of points. One file can contain any number of sections. For example:

JSISCANSATVECTORMARK
{
	body = Kerbin
	color = 255,0,0,128
	vertex = 0,0
	vertex = 0,5
	vertex = 5,5
	vertex = 5,0
	vertex = 0,0
} 

body is the name of the celestial body the section applies to, color is the color to draw the line with -- it is optional and defaults to white. vertex points are <longitude>,<latitude>, i.e. x,y, expressed as degrees with fractional values. This example will draw a square on the map of Kerbin, which starts in longitude 0, latitude 0, goes on to 0,5 and eventually loops back to 0,0 completing the square, using a red color with alpha value 0.5. You can use www.kerbalmaps.com to look up coordinates of the points -- remember that it lists latitude above longitude, while JSISCANsatRPM wants longitude first, latitude second.

JSISteerableCamera

This background handler provides an enhanced camera, allowing buttons in IVA to control not only the camera zoom, but pan as well (aiming the camera side-to-side and up-and-down). Zoom and pan features are smooth and continuous while the associated buttons are held down. The JSISteerableCamera can also optionally display a target icon on the screen to indicate the direction of the current target.

Multiple cameras (with different configurations) can be tied to JSISteerableCamera by listing multiple names in cameraTransform, separated by the pipe symbol '|'. The user can then cycle between the cameras by pressing the button associated with nextCamera or prevCamera.

			BACKGROUNDHANDLER
			{
				name = JSISteerableCamera
				... required settings omitted...
				cameraTransform=ExtCam1|ExtCam2
				fovLimits=40,60|10,60
				zoomRate=10|15
			}

In this example, the handler will use ExtCam1 and ExtCam2. ExtCam1 will have fovLimits of 40 and 60, while ExtCam2 has limits of 10 and 60. The zoom rates are 10 and 15, respectively. The cameraTransform list controls configuration of multiple cameras. If any of the other configuration parameters have longer lists (such as 4 zoom rates, but only 3 cameras configured), the extra parameters are ignored. Configuration parameters are applied in the same order as the camera names. If there are not enough configuration parameters, defaults will be used for the remaining cameras.

When the homeCrosshairColor parameter is set with a non-zero alpha value, a crosshair is drawn on the screen to indicate where the "home" position of the camera is. The home position represents the location where yaw and pitch are both zero. This crosshair also changes in size to represent the zoom level of the camera. The size of the crosshair is controlled by iconPixelSize. If the seekHome button is hooked up, pressing it will cause the camera to automatically center the crosshair.

Caveats:

• Cameras mounted on a ship can clip through the surface of the ship, which looks pretty bad. This is especially easy to see when using negative pitch values, so remember to check how things look at all of the pan extents.

• This module makes use of global buttons. It needs at least one to do anything interactive, and really needs at least two.

    		BACKGROUNDHANDLER
    		{
    			name = JSISteerableCamera
    			method = RenderCamera
    			pageActiveMethod = PageActive
    			showNoSignal = yes
    			buttonClickMethod = ClickProcessor
    			buttonReleaseMethod = ReleaseProcessor
    			...configuration options go here.
    		}
  

Configuration options:

• cameraTransform -- Name of the camera transform that will be used to draw the background for the page. The reserved name CurrentReferenceDockingPortCamera also applies.
• fovLimits -- <maximum>,<minimum> the maximum and minimum field-of-view for the camera, in degrees. The default is (60, 60).
• zoomRate -- controls how quickly the zoom transitions, in degrees-per-second. The default is 0.
• yawLimits -- <left>,<right> the maximum amount the camera can pan to the left and right. Negative values are to the left. The left limit must be zero or less, while the right limit must be zero or more. The default is (0, 0).
• yawRate -- controls how quickly the camera pans from side-to-side, in degrees-per-second. The default is 0.
• pitchLimits -- <up>,<down> the maximum amount the camera can pan up and down. Negative values are down. The down limit must be zero or less, while the up limit must be zero or more. The default is (0, 0).
• pitchRate -- controls how quickly the camera pans up and down, in degrees-per-second. The default is 0.
• zoomIn -- Number of the globalButton that will zoom the camera in.
• zoomOut -- Number of the globalButton that will zoom the camera out.
• yawLeft -- Number of the globalButton that will pan the camera left.
• yawRight -- Number of the globalButton that will pan the camera right.
• pitchUp -- Number of the globalButton that will pan the camera up.
• pitchDown -- Number of the globalButton that will pan the camera down.
• showTargetIcon -- A Boolean (true/false) that controls whether an icon is drawn on the screen in the direction of the currently targeted item. Defaults to false.
• iconPixelSize -- The size of the target icon.
• targetIconColor -- The color of the target icon. Defaults to (255, 0, 255, 255) magenta.
• toggleTargetIcon -- The number of the globalButton that toggles drawing the target icon.
• homeCrosshairColor -- The color of a crosshair that is drawn to mark the "home" position of the camera (where yaw and pitch are both zero).
• flickerChance, flickerRange -- Chance the camera has to randomly lose signal, defaults to zero. The syntax and rules are the same as for normal cameras.
• nextCamera, prevCamera -- The globalButtons that will select the next camera or previous camera connected to this background handler.
• seekHome -- The globalButtons ID that will cause the current camera to seek "home" (return the yaw and pitch to the default 0 setting). It does not affect zoom (unless there's enough demand for that to reset, too).

JSIVariableGraph

This background handler will draw a nice time-based graph of whichever variables you wish. (See Defined variables) Limitations:

• There is no hard limit of number of variables per graph, but all the variables within the same graph will be graphed to the same scale.

• Graph data points will not persist.

    BACKGROUNDHANDLER
    {
    	name = JSIVariableGraph
    	method = RenderGraphs
    	...configuration options go here
    }
  

Configuration options:

• graphSet -- Name of the graph set to draw, see below. Required.
• graphRect -- <left>,<bottom>,<right>,<top> -- Edges of the graph on the screen, in pixels, counting from the bottom left corner of the screen.
• xSpan -- Number of seconds that fits in the graph across X.
• ySpan -- <minimum>,<maximum> -- Minimum and maximum of the graph across Y.
• secondsBetweenSamples -- How often will the values be sampled for inclusion in the graph. Defaults to once per 0.5 seconds.
• borderColor -- Color that will be used to draw the lines denoting the edges of the graph. Defaults to white.
• borders -- 0, 2 or 4. If 0, no borders will be drawn. If 2, two lines will be drawn - the minimum X and minimum Y, this is the default. If 4, all four borders will be drawn.
• backgroundColor -- Defaults to black.
• backgroundTextureURL -- If this URL is present, that texture will be used for background instead of the color.

Defining graph sets

Due to limitations of KSP's configuration reading system, graph sets need to be defined in a separate file. This file must have the .cfg extension, but can be located anywhere within GameData, the appropriate block will be found by name:

JSIGRAPHSET
{
	name = ExperimentalGraphSet
	GRAPH
	{
		variableName = ALTITUDE
		color = 255,0,0,255
	}
	GRAPH
	{
		variableName = HORZVELOCITY
		color = 0,255,0,255
	}
}

• variableName -- Name of a defined variable. You can obviously only use variables that return numbers. You can use a number in place of a variable, which will result in a straight horizontal line, although you probably don't want to.
• color -- Color the graph line will be drawn with.
• floatingMaximum,floatingMinimum -- If either of these parameters is present, the graph of this particular variable will ignore the ySpan settings regarding the minimum and maximum vertical span values -- instead, they will be computed to make the minimum of the graph correspond to the smallest recorded and maximum to the highest recorded value respectively.

You can have any number of separate graph sets or any number of individual variables within the graph set.