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

[Pingonaut]

Seeing as how you have both the old prop and the new prop it's a very obvious case of an incorrect installation. I don't know how exactly you messed it up though.

Well I've deleted all the files and readded them multiple times now.

I don't use ModuleManager 1_5, that one doesn't work for some other mods, I believe. If it is necessary I'll figure something out.

[MOARdV]

I'm not clear what exactly do you mean by a 'single position button'. One that does not stay toggled, but immediately snaps back after being triggered once?

Yes, exactly that. I want to emulate a single-throw, single-position switch (or non-toggle push button). I'm not a modeler, and the example model "only" had 8 buttons, so I wanted to repurpose other buttons by making them non-toggle buttons. In addition to SCANsat support, I had ideas for integrating with another plugin where I would want the additional buttons. I also wanted a button for staging, since that's not an on-off function. All that being said, it sounds like the example prop in 0.9 will suit my needs, so this may be moot (will download it now and take a look).

[Mihara]

Well I've deleted all the files and readded them multiple times now.

If you're still getting the new prop meshed together with the old prop, that just isn't bloody possible because the new package does not even contain the old prop.

I don't use ModuleManager 1_5, that one doesn't work for some other mods, I believe. If it is necessary I'll figure something out.

As far as I'm aware, you believe wrong, but it shouldn't be necessary, 1.3 should still work. The correct location of installation, though, is necessary.

Yes, exactly that. I want to emulate a single-throw, single-position switch (or non-toggle push button). I'm not a modeler, and the example model "only" had 8 buttons, so I wanted to repurpose other buttons by making them non-toggle buttons. In addition to SCANsat support, I had ideas for integrating with another plugin where I would want the additional buttons. I also wanted a button for staging, since that's not an on-off function. All that being said, it sounds like the example prop in 0.9 will suit my needs, so this may be moot (will download it now and take a look).

Well, there is currently no way to make the monitor accept key presses from other props than itself, and it's been proving nontrivial to add, so there would be no way to re-purpose anything, unfortunately, hence my confusion. Background and page handlers receive globalButtons, but the actual button click events are still handled by the monitor itself, though there's nothing stopping the handlers from collecting data, elsewhere, including by installing their own button handlers somewhere else.

As for a staging button, the staging switch in ALCOR immediately snaps back while it is still powered by JSIActionGroupSwitch, because that's how the underlying flag works -- it briefly goes on and then snaps back. While it is visually a switch because that's what alexustas wanted it to be, programmatically it is the same - a model with one animation that moves it between 'on' and 'off' position. Since the 'stage' flag does not remain set after you trigger a stage, the plugin then moves the animation backwards.

[nothke]

..Continued from ScanSat thread:

about those approach funnels. These could be just textures overlaid on top of the scansat image, just like the red dot annomalies are. No need for advanced vectors and such..

[Mihara]

..Continued from ScanSat thread:

about those approach funnels. These could be just textures overlaid on top of the scansat image, just like the red dot annomalies are. No need for advanced vectors and such..

It's problematic to use textures to mark up something which isn't a point. I suppose it shouldn't be much of a problem to compute two points in corners and stretch it, but that will break if map projection is changed. Right now, you can't change it, but the code is written with the assumption that you should be able to, so a different projection should still work... Orbit lines in these screenshots are already vectors, by the way.

Well, tell me about what those funnels are first and how would I know where they should be drawn.

[Deep silence]

This mod makes heavy use of RenderTextures. I suspect that just isn't getting emulated correctly, indeed, try the linux KSP.

You are right, Linux version run your mod smoothly. But does an out of memory when launched with the same mods that run fine with the windows version.

[nothke]

Well, tell me about what those funnels are first and how would I know where they should be drawn.

Those green arrows extending from the runway are the approach lines, they basically tell you that if you are inside them, you will end up going directly onto the runway, they don't really need to be arrows, it could be just a single line extending along the runway axis to a few kilometers from runway on each side. If you could also make them addable so we could add an Island runway and Kerbin city runway too =) that would be great. It's not a priority, I'm just saying it would be very helpful.

[Mihara]

Those green arrows extending from the runway are the approach lines, they basically tell you that if you are inside them, you will end up going directly onto the runway, they don't really need to be arrows, it could be just a single line extending along the runway axis to a few kilometers from runway on each side. If you could also make them addable so we could add an Island runway and Kerbin city runway too =) that would be great. It's not a priority, I'm just saying it would be very helpful.

Well, here's what I'm thinking right now:

	PAGE
	{
		button = buttonR1
		text = JSI/RasterPropMonitor/Example/ExampleMFD/p1_landing40x20.txt
		BACKGROUNDHANDLER
		{
			name = JSISCANsatRPM
			method = MapRenderer
			buttonClickMethod = ButtonProcessor
			pageActiveMethod = PageActive
			...blah blah
			MAPFEATURE
			{
				body = Kerbin
				color = 0,1,0,0
				point = 0.0,0.0
				point = 0.1,0.1
				point = 0.0,0.1
				...
			}
		}
		textureURL = JSI/RasterPropMonitor/Example/ExampleMFD/GPS/noscansat		
	}

Or maybe, instead of an array of points like this in the config file, there would be a reference to a file to load them from, but that makes little difference. "point" is the longitude-latitude of a point on the map, and all points are connected by lines of that color. That is relatively easy to code because all I would need to do would be to code an object to store information on the map feature and load it from configs, and then I could just feed it to the same routine that already draws orbits. It will be easier if you provide the points to test with.

[Mihara]

You are right, Linux version run your mod smoothly. But does an out of memory when launched with the same mods that run fine with the windows version.

Huh.

Well, I don't think I'm at fault for this particular one, (RPM is much heavier on the GPU memory than system memory) but I dunno, try this mod? It can help considerably.

[Pingonaut]

If you're still getting the new prop meshed together with the old prop, that just isn't bloody possible because the new package does not even contain the old prop.

Well, I'll try again, reinstall each file after deleting each one.

Edit: Well I discovered I had accidentally renamed one of the old files and didn't notice. That's the problem! Thanks for the replies.

[CERVERUS]

Your work is awesome Mihara...you add a level up to the KSP Game.

Maybe you can add the MFD and to another pods (personal i like it to the FASA Big Gemini).

Thanks!

[MrTheBull]

Mihara, thanks for this awesom plugin! =D

[Mihara]

Your work is awesome Mihara...you add a level up to the KSP Game.

Maybe you can add the MFD and to another pods (personal i like it to the FASA Big Gemini).

Thanks!

Well, I'll leave that for the authors of particular pods.

If I get enough free time, though, I want to completely remove all props from a stock pod and remake them with my plugin...

[CERVERUS]

Well, I'll leave that for the authors of particular pods.

If I get enough free time, though, I want to completely remove all props from a stock pod and remake them with my plugin...

Great news,thank you for this amazing plugins!!!

[MOARdV]

I spent a good deal of yesterday setting up the new MFD in a KOSMOS VA Capsule, and then tweaking the push switches from the ASET lander cabin to fit my action group layout (changing the labels displayed on the buttons from C01, C02, etc to things like "Release Capsule", "Solar Panels", etc). The SCANsat integration is awesome, and I'm now interested enough to start looking at writing my own background handler for integration with another plugin. I do have some more feedback on the code.

1) Regarding SIP formatting: Can you make the M format 3 digits after the decimal (like the 'k')? I got my orbit display screens all nicely formatted, and then I discovered when I was en route to the Mun that Mm were printed with 6 digits after the decimal, and even with the 9 character space I had set aside for the formatted output, I couldn't fit it (10.123456M is 10 chars). I think dropping the 4th through 6th decimal of accuracy is safe to do. The other request is suppressing micro - that shows up before / after landing in the horiz and vert speeds. milli is probably safe to drop, as well: 0.123 m/s is sufficient, I think.

2) There's a quirk with RPM using a docking port camera assigned to the docking port / parachute parts from Sumghai's SDHI module. The docking port seems to disappear after the parachutes deploy, and the page for the docking port cam won't display any more (it's a gray screen or something - none of the overlay text shows up either - but I can click another page button and that all works). It works prior to parachute deployment. I'll reproduce this and see if there are any errors in the log file. Actually, I'm also using the RealChutes mod, so it may be an interaction between those mods.

3) rbray89's clouds and lights (Visual Enhancements mod) aren't rendered in the docking port cam view. I assume this is something that rbray89 would need to change, but I don't know what to relay to him.

4) You might have already mentioned this - if I have SCANsat background handlers on two pages, they redraw independently. Is there any way to have just one background handler handle both backgrounds (so, if I am on Page 1 with a SCANsat background, and I switch to Page 2, which also uses a SCANsat background, the new page points to the Page 1 SSRPM background hander instead of creating a new and unique instance of it)?

Overall, RPM is a great mod. With the info displays I have in the cockpit, I can fly missions almost entirely from an IVA view. With a couple of more interactive props (resource gauges, a staging button), it'd be almost perfect.

[Chebalu]

MOARdV ! Could I ask your Kosmos VA capsula settings?

[MOARdV]

MOARdV ! Could I ask your Kosmos VA capsula settings?

I can't release the config file directly, per the KOSMOS license. Let me see if I can figure out how to make a Module Manager file that will work.

[MOARdV]

I do have some more feedback on the code.

One other one that I forgot: If you select a location to land using MechJeb, TARGETEXISTS is set to true, but TARGETNAME shows up as "???!" or something similar. I assume MJ is doing something weird to make target a location instead of a vessel, so there's an invalid name for the target. On the plus side, the TARGETDISTANCE also appears valid, so I can track distance-to-target during landing.

[Chebalu]

It would be great! Thanks MOARdV!

[Mihara]

1) Regarding SIP formatting: Can you make the M format 3 digits after the decimal (like the 'k')? I got my orbit display screens all nicely formatted, and then I discovered when I was en route to the Mun that Mm were printed with 6 digits after the decimal, and even with the 9 character space I had set aside for the formatted output, I couldn't fit it (10.123456M is 10 chars). I think dropping the 4th through 6th decimal of accuracy is safe to do. The other request is suppressing micro - that shows up before / after landing in the horiz and vert speeds. milli is probably safe to drop, as well: 0.123 m/s is sufficient, I think.

The problem with this particular bit of code is that it comes wholesale from MechJeb, I have mostly added a thin wrapper to make string.Format use it alongside all native formatters. I can't honestly say I understand it, so alterations to this are going to be tricky, I basically need to rewrite it. I'll see what I can do, though. Getting testable cases where it's not currently behaving to spec would help.

2) There's a quirk with RPM using a docking port camera assigned to the docking port / parachute parts from Sumghai's SDHI module. The docking port seems to disappear after the parachutes deploy, and the page for the docking port cam won't display any more (it's a gray screen or something - none of the overlay text shows up either - but I can click another page button and that all works). It works prior to parachute deployment. I'll reproduce this and see if there are any errors in the log file. Actually, I'm also using the RealChutes mod, so it may be an interaction between those mods.

The camera code looks for a specific named transform, and checks for when the part that houses this transform is no longer part of your vessel. In this case, it appears that the transform is somehow gone, but the part is still attached, which is a situation I forgot to handle. Should be easy enough if I can figure out just in what fashion it ends up destroyed, a log file would give useful pointers.

EDIT: I think I fixed it. Needs testing though, how exactly did you add a camera to that port?

3) rbray89's clouds and lights (Visual Enhancements mod) aren't rendered in the docking port cam view. I assume this is something that rbray89 would need to change, but I don't know what to relay to him.

Mmmm... Interesting, I'll take a look at his source. My guess is that the visual enhancements are either rendered in a layer that is not used normally (and then when my camera copies the stock camera, it ends up doing it before his code modifies it) or that they're added in OnPostRender or something of the sort -- i.e. after all module code is already done, in which case fixing it will be quite nontrivial.

4) You might have already mentioned this - if I have SCANsat background handlers on two pages, they redraw independently. Is there any way to have just one background handler handle both backgrounds (so, if I am on Page 1 with a SCANsat background, and I switch to Page 2, which also uses a SCANsat background, the new page points to the Page 1 SSRPM background hander instead of creating a new and unique instance of it)?

Right now, only if they're in the same prop, which is obviously not the case. This background handler has a pageActive method and does not redraw if the page is not active, so at least if you don't activate it on more than one monitor, it won't hurt your framerate more than it already does.

I could probably convert it to a PartModule (which would involve relatively little code changes) which would make it a bit easier, but the problem with that is that then handling more than one display size per pod would be impossible.

Overall, RPM is a great mod. With the info displays I have in the cockpit, I can fly missions almost entirely from an IVA view. With a couple of more interactive props (resource gauges, a staging button), it'd be almost perfect.

Like I said, I want to eventually gut a stock pod and fit all of alexustas' widgets in there.

One other one that I forgot: If you select a location to land using MechJeb, TARGETEXISTS is set to true, but TARGETNAME shows up as "???!" or something similar. I assume MJ is doing something weird to make target a location instead of a vessel, so there's an invalid name for the target. On the plus side, the TARGETDISTANCE also appears valid, so I can track distance-to-target during landing.

Yes, MJ is in fact doing something weird, because natively a location cannot be a target. I thought there would be no way for the "???!" to show up though, but guess there is. Since I can't directly reference whatever ITargetable MechJeb creates for it without making my plugin inoperative without MJ, I could make it a more sensible string, maybe? Like "ground location"?

EDIT: Well, upon further investigation, MechJeb sets sensible names for it's ITargetable implementations, so I can just return those instead.

Edited December 1, 2013 by Mihara

[MOARdV]

The problem with this particular bit of code is that it comes wholesale from MechJeb, I have mostly added a thin wrapper to make string.Format use it alongside all native formatters. I can't honestly say I understand it, so alterations to this are going to be tricky, I basically need to rewrite it. I'll see what I can do, though. Getting testable cases where it's not currently behaving to spec would help.

The case I have can be expressed as:

{0:SIP9}m123456789012345678901234567890 $&$ APOAPSIS

With that string visible, head to the Mun. The text displayed will surpass 9 digits once you're close to the Mun - {0:SIP9} becomes 10.000000M once the apoapsis is over 10000km, and the last '0' in the numeric string will get pushed off the display. Smaller numbers don't show this behavior. I think a sensible solution would be for the 'M' case to show 3 digits of precision like the others.

I can take a look at that code and see if I can come up with something, if nothing else. I am adept in a number of programming languages, so I can stumble through C# well enough.

The camera code looks for a specific named transform, and checks for when the part that houses this transform is no longer part of your vessel. In this case, it appears that the transform is somehow gone, but the part is still attached, which is a situation I forgot to handle. Should be easy enough if I can figure out just in what fashion it ends up destroyed, a log file would give useful pointers.

EDIT: I think I fixed it. Needs testing though, how exactly did you add a camera to that port?

I used ModuleManager to add a JSIExternalCameraSelector to the part. If you've committed the change, I can pull the source from GitHub and compile it locally to test, correct? I haven't had a chance to reproduce it today, but I hope to have time this afternoon.

Right now, only if they're in the same prop, which is obviously not the case. This background handler has a pageActive method and does not redraw if the page is not active, so at least if you don't activate it on more than one monitor, it won't hurt your framerate more than it already does.

It is the same prop, just two separate pages. I have page 1 with a BACKGROUNDHANDLER = JSIScanSatRPM, and page 2 also has JSIScanSatRPM. I have different text on the overlays. The first time I select each page, the map draws. That is, Page 1 draws the map (full render, with the red sweep line). Then, on Page 2, the same thing happens again, instead of using the rendered map from Page 1. If the ship has moved far enough in orbit between selecting P1 and P2, the map will be centered differently. If I switch back to Page 1, the map shifts back to Page 1's center and icon location. It doesn't redraw the whole thing (with the red sweep line), but it is positioned differently. I don't have an objection to separate props rendering independently - that makes sense. It'd be nice if multiple pages on the same prop could use the same background handler component, instead of each page on the prop having its own instance of the rendered map.

EDIT: Well, upon further investigation, MechJeb sets sensible names for it's ITargetable implementations, so I can just return those instead.

I wanted to make sure it was a handled case one way or the other. I like that I can get distance information in this situation, so if there is a sensible name you can query, that would be awesome.

[Mihara]

I can take a look at that code and see if I can come up with something, if nothing else. I am adept in a number of programming languages, so I can stumble through C# well enough.

That would be nice.

If you've committed the change, I can pull the source from GitHub and compile it locally to test, correct? I haven't had a chance to reproduce it today, but I hope to have time this afternoon.

Just did.

It is the same prop, just two separate pages. I have page 1 with a BACKGROUNDHANDLER = JSIScanSatRPM, and page 2 also has JSIScanSatRPM. I have different text on the overlays. The first time I select each page, the map draws. That is, Page 1 draws the map (full render, with the red sweep line). Then, on Page 2, the same thing happens again, instead of using the rendered map from Page 1. If the ship has moved far enough in orbit between selecting P1 and P2, the map will be centered differently. If I switch back to Page 1, the map shifts back to Page 1's center and icon location. It doesn't redraw the whole thing (with the red sweep line), but it is positioned differently. I don't have an objection to separate props rendering independently - that makes sense. It'd be nice if multiple pages on the same prop could use the same background handler component, instead of each page on the prop having its own instance of the rendered map.

In theory they can (that's what the multiHandler option is for, it will search for another copy of the module in the prop instead of always instantiating a new one). Come to think of it, JSISCANsatRPM should survive using it -- it'll get two page activation calls in a row but that shouldn't be a problem since it just sets a boolean.

[MOARdV]

That would be nice.

I'll see what I can come up with. I noticed just now that when I try to use fixed format (SIP9.3), I get 6 digits of precision when it switched to 'k'.

Just did.

And now I can't reproduce the bug with 0.9 without your change. The camera worked before parachute deployment, during parachute deployment, and after parachute deployment. I guess it decided to make a liar out of me.

In theory they can (that's what the multiHandler option is for, it will search for another copy of the module in the prop instead of always instantiating a new one). Come to think of it, JSISCANsatRPM should survive using it -- it'll get two page activation calls in a row but that shouldn't be a problem since it just sets a boolean.

I overlooked the multiHandler option (that's what I get for not reading all the documentation thoroughly). Adding that in fixed that problem, so this was just end-user oversight, not a bug.

[Mihara]

I'll see what I can come up with. I noticed just now that when I try to use fixed format (SIP9.3), I get 6 digits of precision when it switched to 'k'.

Yes, that's one of those things I know about and don't know how to fix correctly. The original function from MechJeb thinks not in terms of character position, but in terms of significant digits, which is close but not entirely it. I stitched it in but just added hackish wrapping around it, I'm not sure how it really works and you can probably see how radically it's code style differes from mine.

And now I can't reproduce the bug with 0.9 without your change. The camera worked before parachute deployment, during parachute deployment, and after parachute deployment. I guess it decided to make a liar out of me.

Odd. Well, it should cleanly handle more possible cases of the camera transform vanishing now, can't hurt.

I overlooked the multiHandler option (that's what I get for not reading all the documentation thoroughly). Adding that in fixed that problem, so this was just end-user oversight, not a bug.

Mind you, I can't say I'm entirely settled on the API, otherwise I'd call it version 1.0 by now. I still want to cook up some sensible method to handle calling modules across props as well.

[gre8]

Great mod. Flying from the cockpit using only instrumentation is quite a fun challenge.

I'd like to point however, that some of the info seems rather unorganized. For instance, the orbital values AP and PE are neat, but the fact that they are isolated from burn time and d-V makes for some tiresome back and forth clicking.

The orbital parameters screen could benefit from a bit more love and information.

Other than that, I have no complaints about this amazing piece of mod. Congratulations!