[0.25] RasterPropMonitor - putting the A in your IVA (v0.18.3) [8 Oct]

[nli2work]

All RPM IVA. even survived a landing!

[Hyomoto]

It's sort of fun to watch things like this for reasons unintended. May I ask why you have MechJeb AND Flight Engineer installed?

[nli2work]

mechjeb installation is for testing integration with RPM in the MFD prop. and useful for testing VTOL crafts.

[ss8913]

What cockpit is that in the video? Also, why does RPM not seem to work with the stock Mk2 cockpit, but works with all others? I'm using 0.18.3 on KSP 0.25 Windows 32-bit.

[Herra Tohtori]

Is there any way to make HUD appear at optical infinity rather than RTT on the reflector itself? Or is that something that depends on the individual cockpit layout/geometry rather than RPM itself?

[nli2work]

optical infinity as in what... covering the entire game window? or just some projection on no apparent plane in space? the HUD is painted on a plane, you can place it anywhere, even outside the IVA; with or without the frame; transparent or opaque; it's just a matter of configuration and prop setup.

[Herra Tohtori]

optical infinity as in what... covering the entire game window? or just some projection on no apparent plane in space? the HUD is painted on a plane, you can place it anywhere, even outside the IVA; with or without the frame; transparent or opaque; it's just a matter of configuration and prop setup.

Optical infinity meaning the way reflector gunsights and HUDs work. They're collimated so that head movements in cockpit cause no parallax shift in the reflected reticle/display - which is what makes them useful. A reflector gunsight will always point at the same direction, regardless of the position that the pilot looks at it - within certain limits of course, you have to be looking through the sight. Similarly, an artificial horizon in a HUD would be rendered where the horizon is.

Placing the HUD/reticle texture plane outside, ahead of the cockpit would work, but that technique requires sufficient distance and some kind of masking so that the HUD/gunsight is only visible when looked through the actual reflector. But it does sound like this issue is with specific cockpit IVA designs rather than RPM. Thanks for the answer.

[Yarbrough08]

optical infinity as in what... covering the entire game window? or just some projection on no apparent plane in space? the HUD is painted on a plane, you can place it anywhere, even outside the IVA; with or without the frame; transparent or opaque; it's just a matter of configuration and prop setup.

Ha! Making props to display on the outside of the craft..

[nli2work]

Ha! Making props to display on the outside of the craft..

well, not quite. IVA isn't rendered when you are outside unless you are using TransparentPod module. so faking collimated HUD could work if you place the HUD plane far ahead of the IVA and scale it up accordingly.

[artwhaley]

I'm trying to make my first RPM prop... and I'm trying to keep it simple, so I'm starting with a no-buttons primary flight display using all of the pieces from the Alcor display. the Alcor MFD is working right next to my test prop in the IVA, so I know all of the pieces are there...

I've built a blender model that consists of two objects - a beveled plate for the base object, and a single polygon square that sits 1cm in front of that plate, named 'screen'.

EDIT: I'm getting closer.

I can set the 'screen' object's shader to ksp/diffuse and change the prop.cfg 's textureLayerID = to _MainTex and make it show up on the diffuse layer. But when I set the texture layer to _Emissive and change the Unity material shader to ksp/emissive nothing shows up on the screen. I've put a 32x32 white .tga on the emissive layer in Unity, and I've tried both assigning a texture and leaving the diffuse texture blank. I see the screen object as an object... with the diffuse texture (or lack thereof) rendered... but I don't see the rpm screen... or any other sign that the emissive layer is doing something.

I haven't set an emissive texture before in Unity, so it's quite possible I'm just doing something dumb before I even get to the RPM configuration... but...

Setting the shader KSP/unlit and pointing rpm at the MainTex gives passibly good results at a light-up screen... but it seems like most RPM users are using the Emissive layer... so I can't figure out why it's not working for me. Do I need a transparent texture on MainTex for emissive to show through?

The prop.cfg:

PROP{
    name = drmtv


// Primary Flight Display
    MODULE
    {
        name = RasterPropMonitor
        screenTransform = screen
        fontTransform = ASET/ASET_Props/MFDs/Fonts/mainfont
        textureLayerID =_Emissive          // Name of texture layer to work with on the screen surface.
        screenWidth = 40                      // Screen width in letters.
        screenHeight = 20                     // Screen height in lines.
        screenPixelWidth = 720                // Width of the generated screen texture in pixels.
        screenPixelHeight = 720              // Height of the generated screen texture in pixels.
        fontLetterWidth = 16                  // Width of a font character.
        fontLetterHeight = 32                 // Height of a font character.
        cameraAspect = 1.333



        refreshDrawRate = 10
        refreshDataRate = 10

    emptyColor = 150,0,0,150
    buttonClickSound = Squad/Sounds/sound_click_tick
    buttonClickVolume = 0.6
    noSignalTextureURL = ASET/ASET_Props/MFDs/ScreenPlates/nosignal


        PAGE
        {
            name = pALCORPFD40x20
            default=yes
            BACKGROUNDHANDLER
            {
                name = JSIPrimaryFlightDisplay
                method = RenderPFD
                navBallModel = ASET/ASET_Props/MFDs/ALCORPFD/NavBall
                horizonTexture = ASET/ASET_Props/MFDs/ALCORPFD/NavBall000
                staticOverlay = ASET/ASET_Props/MFDs/ALCORPFD/StaticMask
                headingBar = ASET/ASET_Props/MFDs/ALCORPFD/HDG
                headingBarPosition = 0.0 , 0.65 , 0.4 , 0.05
                cameraSpan = 0.75
                cameraShift = 0 , 0.03
                screenAspect = 1
                drawingLayer = 17
            }
            text = ASET/ASET_Props/MFDs/ALCORPFD/ALCORPFD.txt
            textureInterlayURL = ASET/ASET_Props/MFDs/ALCORMFD40x20/bg01    
        }     
    }

    }

Edited November 16, 2014 by artwhaley

[Beale]

Question One:

Perhaps this has been asked before...

But I am wondering if there is possibility of screen-effects for RPM monitors?

It may sound borderline masochistic, but I would really love some low-res black and white screens (Maybe even grain effects, but that's not exactly needed).

Like the Soyuz camera, in a nutshell.

I've been poking around in the code, but, there is a lot of it.

All I could find was this:

// Now that is done, proceed to setting up the screen.

				screenTexture = new RenderTexture(screenPixelWidth, screenPixelHeight, 24, RenderTextureFormat.ARGB32);
				screenMat = internalProp.FindModelTransform(screenTransform).renderer.material;
				foreach (string layerID in textureLayerID.Split())
					screenMat.SetTexture(layerID.Trim(), screenTexture);

private void RenderScreen()
		{
			RenderTexture backupRenderTexture = RenderTexture.active;

			if (!screenTexture.IsCreated())
				screenTexture.Create();
			screenTexture.DiscardContents();
			RenderTexture.active = screenTexture;

			if (needsElectricCharge && electricChargeReserve < 0.01d) {
				// If we're out of electric charge, we're drawing a blank screen.
				GL.Clear(true, true, emptyColorValue);
				RenderTexture.active = backupRenderTexture;
				return;
			}

			// This is the important witchcraft. Without that, DrawTexture does not print where we expect it to.
			// Cameras don't care because they have their own matrices, but DrawTexture does.
			GL.PushMatrix();
			GL.LoadPixelMatrix(0, screenPixelWidth, screenPixelHeight, 0);

			// Actual rendering of the background is delegated to the page object.
			activePage.RenderBackground(screenTexture);

			if (!string.IsNullOrEmpty(activePage.Text)) {
				RenderText(screenBuffer);
			}

			// If we have a text overlay, that's where we print it.
			if (activePage.textOverlayBuffer.Length > 0) {
				RenderText(activePage.textOverlayBuffer, true);
			}

			activePage.RenderOverlay(screenTexture);
			GL.PopMatrix();

			RenderTexture.active = backupRenderTexture;
		}

Maybe I could change the RenderTextureFormat.ARGB32 to RenderTextureFormat.R8?

I think the one method I was interested in (but couldn't find) was "screenTexture.Create();", any chance of pointing me in the right direction?

Thanks!

Question Two:

Is there anyway to separate the dockingNode and camera node?

My docking port has a probe, which means the view from the dockingNode transform is obscured when viewed through RPM camera.

Thanks again!

Edited November 17, 2014 by Beale

[nli2work]

I'm trying to make my first RPM prop... and I'm trying to keep it simple, so I'm starting with a no-buttons primary flight display using all of the pieces from the Alcor display. the Alcor MFD is working right next to my test prop in the IVA, so I know all of the pieces are there...

I've built a blender model that consists of two objects - a beveled plate for the base object, and a single polygon square that sits 1cm in front of that plate, named 'screen'.

EDIT: I'm getting closer.

try this, import the alcore mfd or JSI's example mfd into unity, them remove the prop script. then you can select the pieces of the prop and see some information about it ( but you can't see the hierarchy or edit the parts), check the shader used on the screen objects. The example MFD uses KSP/Emissive with a black texture. I'm betting the white texture is washing out the screen to 100% emissive, any additional emissive doesn't create any contrast and so nothing appears on the screen.

[artwhaley]

@nli2work - I got it to work. I'm not sure exactly which one of the changes I made did it, but looking at the props helped. That's a great tip about spawning and then deleting the script.

@Beale - I was hoping someone smarter would chime in, but if I'm what you've got... I'm no help on getting a black and white monitor working... but I have an IDEA for the docking node, though I haven't tested it, and it has a side-effect. I don't know if the docking camera is spawned by the docking node or the control node, but if it's the control node, you can move the camera to the end of the probe... but the drawback is that, of course, the control reference will be off by that distance... so mechjeb, navyfish's plugin, and RPM will all report that you're 20cm past the docking node before you actually connect. If that compromise is fine with you, my post in the tutorials sticky explains how to set the docking nodes and control nodes separately. Again, I don't know which of the two nodes the camera is set by... but you've got a 50/50 chance that it works!

[MOARdV]

But I am wondering if there is possibility of screen-effects for RPM monitors?

That's been talked about long ago. I don't see why it couldn't be done, although it'd require some shader work. -- actually, you can get flickering effects from the camera already -- see this part of the documentation.

My docking port has a probe, which means the view from the dockingNode transform is obscured when viewed through RPM camera.

The automatic docking node code doesn't provide manual tweaks of the camera as I recall, but you can use JSIExternalCameraSelector. That would allow arbitrary rotations and translations to move the camera "above" the probe. Or you could add a small "camera housing" to the side.

[Beale]

@Beale - I was hoping someone smarter would chime in, but if I'm what you've got... I'm no help on getting a black and white monitor working... but I have an IDEA for the docking node, though I haven't tested it, and it has a side-effect. I don't know if the docking camera is spawned by the docking node or the control node, but if it's the control node, you can move the camera to the end of the probe... but the drawback is that, of course, the control reference will be off by that distance... so mechjeb, navyfish's plugin, and RPM will all report that you're 20cm past the docking node before you actually connect. If that compromise is fine with you, my post in the tutorials sticky explains how to set the docking nodes and control nodes separately. Again, I don't know which of the two nodes the camera is set by... but you've got a 50/50 chance that it works!

That's been talked about long ago. I don't see why it couldn't be done, although it'd require some shader work. -- actually, you can get flickering effects from the camera already -- see this part of the documentation.

The automatic docking node code doesn't provide manual tweaks of the camera as I recall, but you can use JSIExternalCameraSelector. That would allow arbitrary rotations and translations to move the camera "above" the probe. Or you could add a small "camera housing" to the side.

Thank you both very much for the info!

I had no idea about the existing flickering effects...

A small camera housing part may be a better alternative.

@artwhaley: A fine idea! But, a quick test, it seems camera is spawned on DockingNode

Thanks!

Edit: Forgive my ignorance, but where can I apply the flickering effect. Do I have to recompile the mod, or is it a config?

Edited November 19, 2014 by Beale

[nli2work]

you can place the docking node inside the mesh, the camera will be able to see through the back face. you will have to adjust the docking rod so there are no polygons facing the docking node. you could on the other hand take advantage of the mesh as some kind of reticle.

[MOARdV]

Edit: Forgive my ignorance, but where can I apply the flickering effect. Do I have to recompile the mod, or is it a config?

In the config file for the PAGE that has the camera. There are two values - "flickerChance", which is a number between 1 and 1000 that indicates the number of chances out of 1000 that the screen will flicker (so, flickerChance of 100 is a 10% chance; flickerChance of 10 is 1%). The other value is "flickerRange", which is the maximum number of frames that the flicker will be applied - the mod will pick a number between 0 and flickerRange each time the effect is applied, and that's how many frames are messed up.

[Beale]

you could on the other hand take advantage of the mesh as some kind of reticle.

Funnily enough, it has that very effect!

In the config file for the PAGE that has the camera. There are two values - "flickerChance", which is a number between 1 and 1000 that indicates the number of chances out of 1000 that the screen will flicker (so, flickerChance of 100 is a 10% chance; flickerChance of 10 is 1%). The other value is "flickerRange", which is the maximum number of frames that the flicker will be applied - the mod will pick a number between 0 and flickerRange each time the effect is applied, and that's how many frames are messed up.

Thanks a million!

I've found it now

Edited November 19, 2014 by Beale

[Triforce]

Hi all! Is there a way to implement a flight/mission plan in iva? What I would like to do is, to plan my maneuvers by hand/another software that I wrote and then manually execute the burns without manouver nodes. Therefore I would need sort of a easy to edit "list" page where I can enter things like orientation deltaV t+x etc. Is there a mod which is doing this/are there already plans for one?

[artwhaley]

I think I've got an improvement to the RPM code... unless it's actually not an improvement... lol. I saw somewhere one of the authors mentioned that people have said that the relative velocity x,y,and z weren't working 'as expected.' So I dug into them a bit. It seems that they were giving the correct x,y and z velocities relative to the world x,y, and z... not the docking port's x,y,z.

This meant that they weren't numbers that were meaningful for use in docking. ((If I'm wrong about any of that, just ignore me!)) So I started with the code in NavyFish's plugin. I've got it compiled and working... but i've never used github, so I hope I didn't screw up the pull request thing.

Is anyone USING the TGTRELX, TGTRELY, and TGTRELZ, numbers as is for anything? They're displayed on the MFD docking pages... but as far as I can tell, they don't mean anything that can help with docking... and with the code change those numbers would suddenly allow you to actually kill translation relative to the docking port, and you'd be able to create a navyfish style docking assistant for IVA use... but I wanted to ask to make sure I wasn't suggesting something that would break something! The relevant code is:

I commented out the old code, there at the top. (labelled "the way engineer does it.")

	// The way Engineer does it...		//		case "TGTRELX":
		//			return FlightGlobals.ship_tgtVelocity.x;
		//		case "TGTRELY":
		//			return FlightGlobals.ship_tgtVelocity.y;
		//		case "TGTRELZ":
		//			return FlightGlobals.ship_tgtVelocity.z;

                //The way NavyFish does it...
                        case "TGTRELX":

                    if (target != null)
                    {
                            Transform targetTransform = targetDockingNode.GetTransform();
                            float normalVelocity = Vector3.Dot(FlightGlobals.ship_tgtVelocity, targetTransform.forward.normalized);
                            Vector3 globalTransverseVelocity = FlightGlobals.ship_tgtVelocity - normalVelocity * targetTransform.forward.normalized;
                            return Vector3.Dot(globalTransverseVelocity, FlightGlobals.ActiveVessel.ReferenceTransform.right);


                    }else{
                        return 0; 
                    }


                		case "TGTRELY":
                    if (target != null)
                    {

                            Transform targetTransform2 = targetDockingNode.GetTransform();
                            float normalVelocity2 = Vector3.Dot(FlightGlobals.ship_tgtVelocity, targetTransform2.forward.normalized);
                            Vector3 globalTransverseVelocity2 = FlightGlobals.ship_tgtVelocity - normalVelocity2 * targetTransform2.forward.normalized;
                            return Vector3.Dot(globalTransverseVelocity2, FlightGlobals.ActiveVessel.ReferenceTransform.forward);




                    }else{
                        return 0; 
                    }
                		case "TGTRELZ":
                            //cheap way to do this one.. but should be true!
                            return approachSpeed;

[kizentheslayer]

does the external camera button require a separate mod?

[Mecripp]

No did you put a external camera on the craft ?

EDIT- If it had external camera's on it just check your camera numbers make sure there not all the same.

Edited November 23, 2014 by Mecripp2

[kizentheslayer]

No did you put a external camera on the craft ?

didn't go to the editor. Just launched a craft I already had

[ss8913]

ok you guys are all asking very advanced questions about programming new IVAs, which is good, and I may do that at some point, but before that I need to ask a couple of really really dumb questions:

1. My B9 cockpits all have an 'HSI' option under 'NAV' - all I get is a black screen, although I've seen youtube videos of this working. Why isn't mine? I've tried reinstalling RPM and B9, in that order, and in the opposite order, to no effect.

2. Why does the new 0.25 stock Mk2 cockpits not have ANY RPM support?

3. The old stock Mk2 cockpit (the one with the attachment points on both sides, have the RPM support but I can't see out of the cockpit, but I think that's due to the interior modeling not being complete on that part... so I'm really only concerned about #1 and #2 there. any ideas?

[Mecripp]

1 isn't that part of this mod which is like a add on to RPM's http://forum.kerbalspaceprogram.com/threads/85353 do you have it installed, Think that is what your asking and 2 the spaceplane ? there is too cfg for it out so you can pick 1 will hunt them down sec.

EDIT- This 1 is by nli2work http://www./download/12ud82caadrehws/SPPMk2_RPMIVA.zip think he just fix the old one to work in .25 and there is this 1 by MasseFlieger http://forum.kerbalspaceprogram.com/threads/96148-AeroKerbin-Industries-Modified-IVAs

Edited November 23, 2014 by Mecripp2