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

[Drew Kerman]

I just noticed the Date in the Mission Info display is off by a day, seems like it starts at 0 instead of 1 since it reads 2:018:13:44:29 and my game date is actually yr2 d19

[yobeefjerky]

Why is everything saying NaN on the monitors, i did everything right (i think).

[Sentmassen]

I'm getting problems with being locked out of the UI and general game bugging out. Seems to happen, but not limited to, when two vessels close in on each other. I know its this mod or some interaction of it with another because as soon as I got rid of the JSI folder the problem stopped. Has anyone heard of similar problems?

[Wercho]

FYI, the github 0.19 release seems to be different than the dropbox version MOARdv posted in the thread. I installed the latest from github, and it didn't work properly. But when I downloaded from dropbox everything was great. Has anyone else encountered this, or was it just me?

[Sentmassen]

FYI, the github 0.19 release seems to be different than the dropbox version MOARdv posted in the thread. I installed the latest from github, and it didn't work properly. But when I downloaded from dropbox everything was great. Has anyone else encountered this, or was it just me?

Do you have a link to the dropbox? Not seeing where you got that.

[Wercho]

Do you have a link to the dropbox? Not seeing where you got that.

It is in this post: link.

[Siazo]

Is there any way to control the direction selector while IVA?

[MOARdV]

The github 0.19 dev release is the latest dev release with new features for 0.19. If it's not working properly, please provide me enough information for me to determine if there's a bug in RPM - I tested it out a bit before release, and I did not see any problems.

[nicogusuarez]

Hey i'm having a problem with RPM and ALCOR.

http://forum.kerbalspaceprogram.com/threads/110686-Help-with-ALCOR-and-RPM

[MOARdV]

Hey i'm having a problem with RPM and ALCOR.

http://forum.kerbalspaceprogram.com/threads/110686-Help-with-ALCOR-and-RPM

Two questions: First, did you try it with the 0.19 dev version of RasterPropMonitor from GitHub? Second, have you tried any other pods (stock pods, in particular) to see if it's specific to ALCOR?

[nicogusuarez]

Just tried .19 Dev right now and it still has the same error.

Yes, every other pod works except ALCOR.

Edit: .19 Dev

[MOARdV]

Just tried .19 Dev right now and it still has the same error.

Yes, every other pod works except ALCOR.

Edit: .19 Dev

Okay. It sounds like there's something unique about the ALCOR pod that's a problem. I don't know exactly what the issue is - it looks like there are other posts about it on the ALCOR page. If I can find some time, I'll see if I can install the pod and look at it, but I won't make promises for when I'll have time for that. Hopefully someone on the ALCOR thread can provide you some information, since you also asked about it over there.

[nicogusuarez]

Okay!!! Thanks a lot!

People like you make this community awesome!!!

[karamazovnew]

I haven't looked at it, although I see there was a bit of discussion on it back in August in this thread. I've opened a bug on GitHub, and I'll see if I can find time to look into it.

It would be amazing if you could fix it. Apparently all graphic files become black when using "method = RenderHUD". Alpha channels are ok, as can be seen in B9 where the camera screens allow you to see the black hud. In normal RPM screens, you can't see them because of the black background. With Vexcom's hud you can see black lines and text, but with a green halo, making them almost usable. Hope that helps.

By the way, while ago I posted some info on the B9 thread, regarding the use of B9 screens. http://forum.kerbalspaceprogram.com/threads/92630-0-90-B9-Aerospace-Release-5-2-8-%28updated-30-12-14%29?p=1635898&viewfull=1#post1635898. Hope that helps people who want to start making nested interfaces.

[Wavechaser]

OK, MOARdV, after some analyzing, which is basically excluding anything I installed after RPM, and all part mods (like KW) and some plugins that are known to not conflicting with RPM (like MJ, TAC Fuel Balancer, Trajectories, etc.), and these are the suspicious ones:

Procedural Parts

Karbonite that uses Regolith ISRU plugin, which, Regolith is kind of suspicious

Some other not very likely to conflict with RPM but I'm not really sure about: Texture Replacer, TweakScale, Tweakable Everything, Community Resource Pack

[Gaalidas]

Alright, I just did something that... quite honestly... I amaze myself with. I had one problem with the transparent pods. In the editor, everything became very unstable whenever one of those pods were active. after a few days of exploring the source, I discovered that if I added a single check to the starting function of that file (basically an "if (highlolic.issceneineditor) return;") and recompiled, I could get a transparency enabled pod opaque in the editor, but fully functional anywhere else.

With a little more work, that could be made into an option someone could toggle on and off in the part configuration for that pod. Just something the current maintainer might think about implementing. From my tests, it appears to be perfectly stable.

[MOARdV]

Alright, I just did something that... quite honestly... I amaze myself with. I had one problem with the transparent pods. In the editor, everything became very unstable whenever one of those pods were active. after a few days of exploring the source, I discovered that if I added a single check to the starting function of that file (basically an "if (highlolic.issceneineditor) return;") and recompiled, I could get a transparency enabled pod opaque in the editor, but fully functional anywhere else.

That looks like a trivial change that will help out some users. I'll see about adding that as an option and updating the pre-release code. Thank you for finding it.

[Dunbaratu]

I've been toying with the idea of getting into RasterPropMonitor, with the goal of making a kOS computer terminal that appears in IVA view in the cockpit window.

But one problem is that I'm not sure it's possible to have RasterPropMonitor "grab focus" and pass keypresses through itself into the current Page plugin. There appears to be API methods for getting button press information about the buttons along the tops and sided of the monitor, but not for getting keyboard input into it. (Thus people couldn't type into the kOS terminal via RPM - only use the buttons along the side).

I suppose one possibility might be to have my own RPM page plugin be in charge of grabbing keyboard focus from the game instead of having RPM do it, and it could be told to go into "terminal keyboard mode" by the user pressing one of the RPM buttons along the side of the monitor.

[MOARdV]

I've been toying with the idea of getting into RasterPropMonitor, with the goal of making a kOS computer terminal that appears in IVA view in the cockpit window.

But one problem is that I'm not sure it's possible to have RasterPropMonitor "grab focus" and pass keypresses through itself into the current Page plugin. There appears to be API methods for getting button press information about the buttons along the tops and sided of the monitor, but not for getting keyboard input into it. (Thus people couldn't type into the kOS terminal via RPM - only use the buttons along the side).

I suppose one possibility might be to have my own RPM page plugin be in charge of grabbing keyboard focus from the game instead of having RPM do it, and it could be told to go into "terminal keyboard mode" by the user pressing one of the RPM buttons along the side of the monitor.

One of the problems RPM has is that using the current input methods in IVA (hitting collider boxes with mouse clicks) is painfully slow to use for anything more than trivial actions. Mihara has had a long-open bug/feature to add the ability to edit maneuver nodes, for instance.

I think the idea of having an RPM button put RPM into "terminal keyboard mode" is a good one to try. I don't have time right now to work it out, but if you have some ideas how to do so, let me know (or if you want to implement it, I'll be happy to review the design and help adjust it to fit well with RPM).

[Gaalidas]

That looks like a trivial change that will help out some users. I'll see about adding that as an option and updating the pre-release code. Thank you for finding it.

No problem. Also, I noticed last night, when expanding my addon to add a config-level setting, that is did not actually quote my code accurately in the last post. However, I think it will be easier to let you just start typing it in and your favorite dev program should suggest the correct methods. By adding to the "if" check a check against a public bool I called "disableInEditor" (defaults to false) I managed to make it into a configuration option in the module. It's incredibly easy to add these kinds of options to modules that, when looked at in the code, are surprisingly simple considering what they do in-game.

I do hope, however, that your WIP code is more up-to-date than the stuff in github. I had to do some creative things to some of the other source files to make the thing even compile. I'm not even sure what I did in a few of those cases, as I was just letting SharpDevelop do the work for me.

- - - Updated - - -

One of the problems RPM has is that using the current input methods in IVA (hitting collider boxes with mouse clicks) is painfully slow to use for anything more than trivial actions. Mihara has had a long-open bug/feature to add the ability to edit maneuver nodes, for instance.

I think the idea of having an RPM button put RPM into "terminal keyboard mode" is a good one to try. I don't have time right now to work it out, but if you have some ideas how to do so, let me know (or if you want to implement it, I'll be happy to review the design and help adjust it to fit well with RPM).

Input into games from a modding point of view has been a real bugger for many years now. I remember when I was too new to anything coding related to even wrap my midn around the scripting system in Morrowind, and back then we basically had to create a GUI keyboard that was very slow because of a standard "heartbeat" delay to the script execution system. what we really need is something for RPM that will temporarily lock all keyboard input (and perhaps lock your camera to the specific terminal while doing so, though I have no clue on this one) and relay it to the input in a specific terminal. I already know that locking input to the game is possible while still allowing GUI access with a mod I installed a while back (forgot its name, oops) but for relaying the keyboard input to the console afterwards... the only idea I have is somehow setting up every key on a standard keyboard as a hotkey that, when the conditions of the game-action lock and the focus on the terminal are set, output their corresponding key designation.

However, one idea comes to mind which might help figure this out. We already know how to lock game-action input when a text-field in a mod's GUI is active. Perhaps we can find a way to spawn a GUI-based text-input field when a specific RPM cockpit button is pressed. It's not ideally immersive, but it might be a good stepping stone.

Somehow (I'm not sure why or how) this all leads me to mention an idea I've had for some time. It's kind of like a reverse RPM monitor thing. The idea behind RPM was to put the console monitor into the cockpit, but there are times I find myself wishing I could undock the monitor from the cockpit and take it with me into other camera views. This is something I have missed since starting to run KSP after a year or so flying in the Orbiter Flight Simulator. It's the external MFD. I'm wondering how hard it would be to basically take the RPM system, with all of it's side buttons and stuff, and put it into a GUI window so that you could display a complete RPM screen separated from the physical scene.

Now that I'm becoming more familiar with the RPM code, I may start looking into that myself... but I am horribly uneducated in the ways of C# and I'm really just a fiddler when it comes to KSP modding.

UPDATE: I meant to mention this, but I thought that someone had already tried to make a few steps in integrating RPM with kOS. It might be Aa feature in the ALCOR pod. all I remember is a kOS folder in the RPM pages that comes with the pod, but as I am not a kOS user (yet...) I just removed it. It may just be a re-state of whatever is already in the standard input for kOS, but it would be a start.

Edited February 23, 2015 by Gaalidas

[Wavechaser]

OK, MOARdV, after some analyzing, which is basically excluding anything I installed after RPM, and all part mods (like KW) and some plugins that are known to not conflicting with RPM (like MJ, TAC Fuel Balancer, Trajectories, etc.), and these are the suspicious ones:

Procedural Parts

Karbonite that uses Regolith ISRU plugin, which, Regolith is kind of suspicious

Some other not very likely to conflict with RPM but I'm not really sure about: Texture Replacer, TweakScale, Tweakable Everything, Community Resource Pack

Hello? MOARdV? Anybody there?

Repeat, Procedural Parts may conflict with RPM!

[Drew Kerman]

I just noticed the Date in the Mission Info display is off by a day, seems like it starts at 0 instead of 1 since it reads 2:018:13:44:29 and my game date is actually yr2 d19

Also this. Just a minor error

[MOARdV]

Hello? MOARdV? Anybody there?

Repeat, Procedural Parts may conflict with RPM!

Yes, I heard you the first time. I appreciate your desire to have this conflict resolved, but please understand that maintaining RPM is a hobby of mine. It is something I do in my scant free time. Since I don't use Procedural Parts, nor any of the other mods you've listed as potential conflicts, I am not in a position right now of characterizing the problem. When I have time to download these mods, try them out, and test for compatibility, I will do so, but it's not happening today, nor any time in the immediate future. I'm sorry if that is a problem, but since this mod doesn't pay my bills, it's not on the top of my priority list.

[Gaalidas]

Also note that procedural parts has been the cause of many incompatibility problems in countless other mods. It may not be something fixable on this end. Just something to keep in mind. Like an argument, incompatibility is a two-way problem.

[karamazovnew]

Hello? MOARdV? Anybody there?

Repeat, Procedural Parts may conflict with RPM!

You must be doing something wrong when installing rpm. Try backing up your game folder, reinstall a new one in steam, then add RPM with the necessary dependencies and test again (I am assuming you're using 32bit on windows). If it works, start adding mods and see what breaks it. I recommend using a mod manager, I use a simple one like JSGME (Generic Mod Enabler). Ain't perfect, but makes reinstalling mods easy, plus it warns you when you overwrite something. Normally, neigher Regolith, nor Procedural Parts should cause problems, I'm using all of them with no bugs in forever. I've also used it with Realism Overhaul. No issues there either, and that one uses Real Fuels on top of Procedural Parts.

Here's a few things you should be aware of:

- As stated before, OpenGL mode breaks the hud, it's there, but it's black. DirectX11 mode works well.

- In Career, the orbit screen is bugged (you can't see the orbit circle) until you unlock the Tracking Station Conics.

- KerbQuake works fine.

- Quick IVA works fine.

- B9 might not have the latest RPM. Delete the JSI folder in that mod before you install it! You don't need it, the B9 cockpits work just fine without it.

- Modified IVA. No problem, doesn't overwrite anything, just make sure to use the ASET Props in the correct folder. For the MK1 inline cockpit you need to have the correct cockpit mod. Otherwise you'll just have the closed RPM cockpit.

- Vesel View doesn't overwrite anything so it's safe. It has an issue with one screen, but nothing gamebreaking.

- Nav Tools doesn't overwrite anything so it's also safe.

- Docking Port Alignment must be installed AFTER RPM. If you don't, the screen will freeze when you try to start that page, it will lock the buttons for that screen, and mess up a few pages on the other screens too.

- Probe control room is safe, but the new interior remake uses B9 cockpits, you can easily turn them into normal RPM screens in the config file. You must use the required dependencies, B9 props/sounds and ASET Props.

- The only one I didn't use lately is Engine Igniter, but I don't recall any issues with it before, except that in B9 you had to modify the screens (look for the link in my previous post here, previous page).

Edited February 24, 2015 by karamazovnew