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

[Mihara]

Sorry, its probably me that's over complicating the wording here...

Basically, the forward/aft component of surface velocity, plus the left/right component of surface velocity. (fore/aft and left/right in terms of the spacecraft)

horzVelocityForward = Vector3d.Dot(velocityVesselSurface, forward);

horzVelocityRight = Vector3d.Dot(velocityVesselSurface, right);

Is that correct? If it is, well, done -- HORZVELOCITYFORWARD and HORZVELOCITYRIGHT.

[Hyomoto]

I just looked over the documentation and yeah, I think I can get that to work. It's a bit ugly, but that shouldn't matter. I'm going to put together a basic file today to see what I can do. Thanks Mihara! This should really open up some great possibilities.

EDIT: Between CONTEXTREDIRECT and disableSwitchingTo, there is a whole world of options available. But I'm not sure which is preferable. To do the same thing requires pretty much the same number of lines. I can either disableSwitchingTo a page I don't want, or CONTEXTREDIRECT to a page I do. Is that correct? Also, I have a question about using a global button as a context redirect.

PAGE
{
	button = button_A
	name = flightpage1
	CONTEXTREDIRECT
	{
		redirect = pageup, flightpage2
	}
}

PAGE
{
	button = button_UP
	name = pageup
}

PAGE
{
	name = flightpage2
        CONTEXTREDIRECT
	{
		redirect = pageup, flightpage1
	}
}

So, here's three definitions. One for the A key, one for the up arrow and one buttonless page. Once I press 'A', now the up arrow allows me to switch between pages 1 and 2 and pressing A always takes me to page 1. However, what isn't covered in the manual is what happens if you now switch to, for instance, JSITargetHandler. Do I need to use lockingPage or disableSwitchingTo? How will adding a PAGE definition affect buttons being used globally in other pages?

Edited December 29, 2013 by Hyomoto

[Mihara]

But I'm not sure which is preferable. To do the same thing requires pretty much the same number of lines. I can either disableSwitchingTo a page I don't want, or CONTEXTREDIRECT to a page I do. Is that correct?

Pretty much, yes. There is one extra thing that you can probably exploit but I don't recommend you actually rely on because I can't guarantee it will remain like this forever: If a globalButton doubles as a page button, upon pressing it, the page switch (if it was not forbidden by disableSwitchingTo or lockerPage -- and with the redirect as defined) will happen first, but then the globalButton press will happen anyway, but to the newly activated page.

Also, I have a question about using a global button as a context redirect.

...

So, here's three definitions. One for the A key, one for the up arrow and one buttonless page. Once I press 'A', now the up arrow allows me to switch between pages 1 and 2 and pressing A always takes me to page 1. However, what isn't covered in the manual is what happens if you now switch to, for instance, JSITargetHandler. Do I need to use lockingPage or disableSwitchingTo? How will adding a PAGE definition affect buttons being used globally in other pages?

A handler defined within a page is essentially an element of that page that takes the place of the usual text or background. The page object takes care of instantiating it, attaching it to an internal prop, sending it globalButton presses (as numbers which the handler compares to it's configuration options) and calling upon it to return text and graphics. I.e. the handler's button receiver function actually gets a number that it compares to the number that was configured when it was instantiated. It knows nothing of the globalButton list, the number you give in the *HANDLER{} block is what it will compare the number it receives to when a globalButton gets pressed.

As long as the 'multiHandler' option is not involved, every time a handler block is defined, a completely separate copy of the handler module is created. (I.e. JSITargetMenu has options for 'buttonHome', etc, but these are numbers which can be completely different for different copies of JSITargetMenu) The handler itself doesn't even know what called it or why, and can't actually know. (There's a very good reason for this: This way, you can write a plugin for RPM without a hard link dependency on RPM DLL, i.e. as part of some completely different mod that only optionally provides RPM with text or graphics when RPM is configured to ask for them. As long as you provide methods with appropriate signatures and provide a module RPM can load and attach to a prop, it makes no difference to RPM what you call it and what else is that module is doing.)

So the only thing you have to worry about is whether the button configuration options of the handler actually match globalButtons that particular page you're defining it on will accept and mean what you want -- as well as trying not to create too many copies of the handler. (In particular, I recommend avoiding using more than one instance of the PFD, because it creates free-floating objects -- the less of them you have the better.)

P.S. Yeah, it's convoluted. I hope it will be a consolation to you that in the beginning, I just wanted a lander can that doesn't suck and talked alexustas into making one. Then I tried to help him adapt a Firespitter monitor. Then it snowballed out of control...

P.P.S. If that makes it easier, I can make a globalButton renumbering option in the CONTEXTREDIRECT block.

P.P.P.S Well, I just went ahead and made it, check the docs.

Edited December 29, 2013 by Mihara

[therealcrow999]

Finally got around to use this in game. Did a orbit and return mission all in IVA. It was really nice, felt like a different game. All that is missing is someone to do a first person view in EVA. The closest thing I found was this mod, but its outdated. I'm sure it could run without a part.

http://kerbalspaceprogram.com/bbi-first-person-view/

[Hyomoto]

P.P.P.S Well, I just went ahead and made it, check the docs.

I think I actually did a bad job asking a question, and you did a amazing job answering it. For example, the up arrow is assigned as a global button for JSITargetHandler, but it has a page definition, so now what happens? And I think you pretty much answered that one straight away. Right now both events happen, but if I understand it, the PAGE event happens first. So my I need to make sure to disableSwitchingTo to prevent it from changing the page so it can interact with the target display instead, correct?

I went ahead and just pulled the master to look at, and test your latest changes. There's another variable I'd like to add for authenticity and gives me an excuse to play with your prop and learn a bit about modding KSP. But it brings me to another question, which has to do with string.format. This is the variable I added:

                case "RADARALT_MASK":
                    double altitudeMask = altitudeTrue;
                    if (vessel.mainBody.ocean)
                        altitudeMask = Math.Min(altitudeASL, altitudeTrue);
                    if (altitudeMask > 3000)
                        return -1d;
                    return altitudeMask;

So, if I put this into the page file:

  {0:SIP_6.3;"---"} $&$RADARALT_MASK 

I would expect above 3000 meters RADARALT_MASK returns -1d and it will display ---, but it just shows -1.

 {0:#,###m;"---"} $&$RADARALT_MASK

This, however, will work. I looked at the SIFormatter but the only thing I can guess is that it is being formatted BEFORE string.format gets a hold of it so I'm not getting -1, I'm getting something like " -1 " instead. Is there another way around this or is it just a limitation of the SI formatting? By the way, I think the SI format is also a little inaccurate. It must be rounding up since its returns appear about five hundred meters off.

Edited December 29, 2013 by Hyomoto

[Roxette]

Finally got around to use this in game. Did a orbit and return mission all in IVA. It was really nice, felt like a different game. All that is missing is someone to do a first person view in EVA. The closest thing I found was this mod, but its outdated. I'm sure it could run without a part.

http://kerbalspaceprogram.com/bbi-first-person-view/

I just use modulemanager to add this to pods :

@PART[*]:HAS[@MODULE[ModuleCommand]] {

MODULE {

name = ModuleKrEquipKerbal

count = -1

range = 25

guiName = Equip VRGs

MODULE

{

name = BBIFirstPersonView

}

}

}

The problem now is since .23 in eva the kerbal, and hence the view, no longer rotates on the vertical axis, so it's close to unusable unless you only move horizontally.

[Hyomoto]

And they were kind enough to release the source so we can totally update it.

[nubcaker]

Can I just say I love you for this, Mihara? I just did a simple orbit and return with an Orion replica, all in IVA, and it was a total new experience. Before, I wouldn't dare to go IVA to launch my craft, but damn, the displays, the abundance of information, the small fonts, I just LOVE IT.

No seriously, thanks.

PS: does B9 aerospace utilize this? Would be awesome.

[Mihara]

Right now both events happen, but if I understand it, the PAGE event happens first. So my I need to make sure to disableSwitchingTo to prevent it from changing the page so it can interact with the target display instead, correct?

Yes, that's mostly it.

I went ahead and just pulled the master to look at, and test your latest changes.

In case you missed it, I remind you that the front page of the wiki has a link to a prebuilt binary package which is always as-it-is-on-the-wiki (and sometimes a few minutes ahead).

Is there another way around this or is it just a limitation of the SI formatting?

Mostly it is a limitation. It can be removed in theory, but the only way to do it that I can think of introduces the performance penalty of using regular expressions, which I'm not sure is really worth it.

By the way, I think the SI format is also a little inaccurate. It must be rounding up since its returns appear about five hundred meters off.

You'll have to take that one up with MOARdV, that particular formatter has always been a problem for me.

And they were kind enough to release the source so we can totally update it.

Where? I might actually create a refurbished version if the license is GPL as the original binary package says it is.

[Mihara]

PS: does B9 aerospace utilize this? Would be awesome.

Not yet, but there's always hope... and ModuleManager patches, check your B9 cockpits.

[nubcaker]

Not yet, but there's always hope... and ModuleManager patches, check your B9 cockpits.

I see, they use some kind of display, but ehh, not as impressive as these.

[Mihara]

I see, they use some kind of display, but ehh, not as impressive as these.

Go check again with RPM installed, because RPM includes patches to the tune of:

@INTERNAL[B9_Cockpit_S2_Internal] {

	MODULE {
		name = InternalCameraTargetHelper
	}

	PROP
	{
		name = RasterPropMonitorExampleMFD
		position = 0.3177514,0.4179461,-0.1573321
		rotation = -0.03385292,0,0,0.9994268
		scale = 0.75,0.7500001,0.7500001
	}
	PROP
	{
		name = RasterPropMonitorExampleMFD
		position = -0.317751,0.417946,-0.157332
		rotation = -0.03385299,0,0,0.9994269
        scale = 0.75,0.75,0.7500001
	}

}

[Hyomoto]

Where? I might actually create a refurbished version if the license is GPL as the original binary package says it is.

Whoops, that one was a bit of sarcasm. They came back to post in the comments that it was dead, so I was just being a dork. I've gotten the buttons to work as expected, it seems the simplest way to do it is to set up dummy pages for each button, disable the ones you don't want to use and redirect the ones you do.

	disableSwitchingTo = btn4, btn5, btn6, btn7, btn8, btn9, btn0, up, down, enter, home, escape
	CONTEXTREDIRECT
	{
		redirect = btn1, flightdisplay
		redirect = btn2, orbitinfo
		redirect = btn3, altitudegraph
	}

It requires you do it for each and every button but you can be explicitly certain there will be no unintended behaviors, so yeah, it turns out when you use them together it works great! As far as dev builds, I looked but honestly I'm real familiar with gitHub and I couldn't find one. Now that you pointed it out, it's pretty easy to find. So far it's been working nicely.

[Mihara]

It requires you do it for each and every button but you can be explicitly certain there will be no unintended behaviors, so yeah, it turns out when you use them together it works great!

Well, it looks pretty horrible, but that's the best I can come up with without rewriting major segments of the code and changing the syntax entirely yet again, so I hope it's sufficient.

[Hyomoto]

I notice that both the 15000 and 15001 textures are being used on the model, but can I ask what the second one is being used for? I have some silly ideas where I could potentially make the buttons look backlit. Is that the purpose?

[Mihara]

I notice that both the 15000 and 15001 textures are being used on the model, but can I ask what the second one is being used for? I have some silly ideas where I could potentially make the buttons look backlit. Is that the purpose?

15000 is the _MainTex layer, 15001 is the _Emissive layer. The buttons are in fact essentially backlit already.

[Taki117]

Question: I Have a Mod Command Pod (Specifically the one from the Deep Space Mission Pack) that uses the mk 1-2 internal but the monitors aren't showing up, what do I need to change in the Config to cause the desired behavior? (Note that all the Stock indicators are there, and the Side lights did change)

[MOARdV]

By the way, I think the SI format is also a little inaccurate. It must be rounding up since its returns appear about five hundred meters off.

Is there a specific range of values that's a problem? The rounding should follow round-nearest, which is typical for floating point values. I haven't seen anything grossly in error in the hours I've spent looking at the display, but maybe there's something I overlooked when I refactored the MechJeb SI conversion code.

[Mihara]

Question: I Have a Mod Command Pod (Specifically the one from the Deep Space Mission Pack) that uses the mk 1-2 internal but the monitors aren't showing up, what do I need to change in the Config to cause the desired behavior? (Note that all the Stock indicators are there, and the Side lights did change)

You need to create a ModuleManager patch for your command pod:

@PART[PartNameOfThatModPodGoesHere]
{
	MODULE 
	{
		name = JSIInternalPersistence
	}
	@INTERNAL {
		@name = PodCockpitRPM
	}
}

Edited December 30, 2013 by Mihara
oops, that was for a 0.13 version, fixed.

[Hyomoto]

Is there a specific range of values that's a problem? The rounding should follow round-nearest, which is typical for floating point values. I haven't seen anything grossly in error in the hours I've spent looking at the display, but maybe there's something I overlooked when I refactored the MechJeb SI conversion code.

Well, it's likely unnoticeable at high altitudes. I noticed it at the sub 3km range once you hit 1km. Why that range? Just watch the radar altimeter on the MFD versus the analogue one and you'll see it lags behind by about five hundred meters. I know the value being returned by RADARALT isn't the problem because if you format it using #,### (basically not using SI) it matches the gauge precisely.

Mihara, after a lot of work, I finally got the framework done for a menu-based MFD. The only minor issue is when using pageTitle for PAGEHANDLER. Does it make use of string.format as well? You cannot use natural leading spaces because it treats " as a literal character, and any white space just gets truncated. I did a quick workaround by placing a . as the first character (which you can see in the fifth screenshot along the top edge in the left corner. It works and is mostly ignorable but I'd rather not resort to a 'hack' to if I can make it display appropriately.

From left to right, top to bottom: Root menu, Flight Displays, Status Displays, Cameras, Targeting, GPS.

Oh, and thanks for answering my questions! I'm really looking forwards to playing with some of the new stuff you are working on.

Edited December 30, 2013 by Hyomoto

[Mihara]

The only minor issue is when using pageTitle for PAGEHANDLER. Does it make use of string.format as well? You cannot use natural leading spaces because it treats " as a literal character, and any white space just gets truncated.

I don't remember if it is always string.formatted or not (I think all modules do, but maybe there is one I forgot) but remember - tags work regardless of string.format substitution and are processed late in the sequence, right during actually drawing the characters. So you can start the line with a tag that won't actually change anything, and the tag will get quietly consumed on printing, while giving you the result you want: "[@x0] your centered title".

As a side note, you can also use nudge tags to push around the symbols so that they more closely correspond to actual buttons -- that's one of their actual intended uses. And in the dev version, "F1" will save screenshots from inside all monitors to your screenshot directory at the same time as it takes the screenshot of the entire screen, it makes pixel nudging much easier.

[MOARdV]

Well, it's likely unnoticeable at high altitudes. I noticed it at the sub 3km range once you hit 1km. Why that range? Just watch the radar altimeter on the MFD versus the analogue one and you'll see it lags behind by about five hundred meters. I know the value being returned by RADARALT isn't the problem because if you format it using #,### (basically not using SI) it matches the gauge precisely.

I tried out RADARALT using #,###, SIP, SIP6, and SIP9.3, and I can not reproduce any error. SIP (with no format specifiers) will display the nearest appropriate value (eg, 2750 -> 3k), which is correct behavior (round nearest). SIP6 shows 2.750 in this case, as does SIP9.3. All of the values are correct. If you can provide me the specific formatting string you are using, and which variable you are tying to it, I will try again, but I don't see anything wrong.

[Mihara]

So I asked Alexustas to make me a hatch for the Mk1-2 pod, which does not have one on the inside natively.

And he did! I'm probably going to need to fiddle with the placement a bit more though, but that's better than not having one at all.

[Hyomoto]

Well, according to the externals ... it's SOMEWHERE around there.

[Albert VDS]

@Mihara: Could you add the ability view Hullcams through the monitor. Something like a list where you select all the cameras on the vehicle.