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

[DasBananenbrot]

And let me continue my regular showing off sessions.

~SNIP ~

Most of you probably didn't know that Mk1 lander can actually has a hatch on the inside, because normally you can't turn your head around to see it. Well, now you can.

You will need to, because doubleclicking on that cross will make your kerbal go EVA. Every stock capsule that has an EVA hatch visible on the inside is now equipped with this feature, including the crew cabin -- the kerbal you're currently controlling will be the one that goes EVA.

OH MY..... That is awesome. My jaw just dropped ten meters into the ground XD

[Hyomoto]

Mihara you may want to look into this even though it is abandoned, it was a great idea

Also first person eva just use Lazor

Edit: if you have trouble finding a video of what LSI does than look

I don't see a first-person Kerbal component. I used to use the docking cam, but its one of the mods that has a immediate a noticeable effect on my framerate. It also turned out to be wildly redundant once you learn how to intercept/dock, and if you really want it you can get a better function here since it looks freaking awesome.

[Mihara]

I don't see a first-person Kerbal component.

I don't think there is one in Lazors. There is http://kerbalspaceprogram.com/bbi-first-person-view/ but it doesn't work and while the license is technically stated to be GPL, there is no source bundled with it so there's no way to just go and try to fix it.

[Roxette]

I don't think there is one in Lazors. There is http://kerbalspaceprogram.com/bbi-first-person-view/ but it doesn't work and while the license is technically stated to be GPL, there is no source bundled with it so there's no way to just go and try to fix it.

I fixed that one for my own use ages ago, IIRC it was just a config file edit that was needed.

[Mihara]

I fixed that one for my own use ages ago, IIRC it was just a config file edit that was needed.

Well, less work for me then.

P.S. Oh, and resuming the showing off:

Guess what I coded early this (local time) morning.

[lincourtl]

I just tried this out tonight. Beautiful!

Is this a minor bug though?

[LOG 00:15:26.497] [FLIGHT GLOBALS]: Switching To Vessel Leapfrog ---------------------- 
[LOG 00:15:26.501] Camera Mode: FREE
[ERR 00:15:27.527] Actor::updateMassFromShapes: Compute mesh inertia tensor failed for one of the actor's mesh shapes! Please change mesh geometry or supply a tensor manually!
[ERR 00:15:27.529] Actor::updateMassFromShapes: Compute mesh inertia tensor failed for one of the actor's mesh shapes! Please change mesh geometry or supply a tensor manually!

...

[ERR 00:15:27.937] Actor::updateMassFromShapes: Compute mesh inertia tensor failed for one of the actor's mesh shapes! Please change mesh geometry or supply a tensor manually!
[LOG 00:15:28.288] stage manager resuming...

[yeliabmit]

Actually, try using the debloated internals, and unchanged RPM internals with this ModuleManager patch:

https://dl.dropboxusercontent.com/u/532373/debloat-support-patches.cfg

If you report success, I'll post it in the OP.

EDIT: Actually, I just tested it myself. Took a while to get it to work because MODEL nodes don't have a name and I had to dig into ModuleManager source to find the syntax. But it definitely works now, though I think it requires ModuleManager 1.5.6.

FWIW, I just installed the cfg file you provided to GameData/JSI, and all the cockpit internals are working fine now. I have MM 1.5.6 installed. Thanks for the quick fix!

[Mihara]

Is this a minor bug though?

It probably is... But I am pretty sure it's not one of mine. At least, I did suspect the components the navball module generates when I saw this error message (it needs to create an actual navball to show it to you on a screen, silly as it sounds) and subjected them to quite some scrutiny, but could not conclusively implicate the programmatically created meshes -- and I haven't seen that message in my own logs for quite a while.

[lincourtl]

It probably is... But I am pretty sure it's not one of mine. At least, I did suspect the components the navball module generates when I saw this error message (it needs to create an actual navball to show it to you on a screen, silly as it sounds) and subjected them to quite some scrutiny, but could not conclusively implicate the programmatically created meshes -- and I haven't seen that message in my own logs for quite a while.

Ah, I hadn't noticed that particular message before adding RasterPropMonitor, but no biggie. It could well be interaction with another mod though. Also, I play with reduced graphics settings because my system is not the strongest.

I think you can see the artifacting in this video I recorded of that same flight. Starting at about 20 seconds in, but then it seems to go away after awhile.

On edit: No, that part of my log would have been before I switched to IVA view, so I don't think that's it.

Edited December 28, 2013 by lincourtl

[Read have Read]

When I set the a docking port to a reference part to get a target camera view, my debug log gets spammed with NullReferenceException: object reference not set to an instance of an object. Stops when I change the reference part back to the command pod.

[MaHuJa]

If you use RPM but do not use MechJeb, MechJebRPM.dll will fail to load (as intended!) and trigger this bug.

In my case, not only kethane but scansat, lazor, and probably more I don't remember/didn't discover, failed. It was pretty arbitrary which ones worked, as if it failing to load blocked the rest from loading properly.

Here's the kicker: one of the plugins that did load, and work correctly, was... Mechjeb.

Any clues here? What versions should it be working with?

[Hyomoto]

I see that the targeting panel has the ability to use menus and context buttons, but it appears hard-coded into the pagehandler itself. I'd like to make a few requests, the first being what I hope is the most important, 'page levels' which would be part of a PAGE definition, that only matches the current page level. We would be able to set the current page level, and set the page level to match. If the page level is omitted, it would simply work as it does now and always match. That way we could write proper multi-function routines.

My second request is for a special cameraTransform, ExtcamNext and ExtcamPrev. Your current example prop uses eight PAGE definitions to do what ExtcamNext would take one to do. An added benefit could be that it cycles between existing cameras, so if you don't have eight cameras on your ship, it will loop over at the last one, or if you have none it just sticks at Extcam1. With this comes the request to be able to get the current camera ID as a variable that we can then use to display it at the top of the screen.

Here's a example file to sort of demonstrate what I'm asking for. It basically shows how when the second menu is activated, button 1 is used to toggle the camera, but when the first menu is active it is used to display orbital characteristics. I'm not saying this is what I'd do with it, but hopefully it shows off what I'm asking for.

PAGE
{
button = button_A
setpageLevel = 0
text = Top Menu
}
PAGE
{
button = button_B
text = External Camera 1
setPageLevel = 1
cameraTransform = ExtCam1
zoomFov = 10,30,5
zoomButtons = 0,1
} 
PAGE
{
button = buttonR2
pageLevel = 0
text = JSI/RasterPropMonitor/Example/ExampleMFD/p2_orbit40x20.txt
textureURL = JSI/RasterPropMonitor/Example/ExampleMFD/bg01	
} 
PAGE
{
button = buttonR1
pageLevel = 1
text = External Camera $&$EXTCAMID
cameraTransform = ExtCamNext
zoomFov = 10,30,5
zoomButtons = 0,1
}

And lastly, the most horrendous request. Is it possible we could also get a _STAGE suffice for resource variables? Ie: FUEL_STAGE, FUEL_STAGE_MAX?

Edited December 28, 2013 by Hyomoto
To provide better examples and tie it altogether

[Helix935]

I don't see a first-person Kerbal component. I used to use the docking cam, but its one of the mods that has a immediate a noticeable effect on my framerate. It also turned out to be wildly redundant once you learn how to intercept/dock, and if you really want it you can get a better function here since it looks freaking awesome.

trust me it does and it works now too because i use it

[Mihara]

When I set the a docking port to a reference part to get a target camera view, my debug log gets spammed with NullReferenceException: object reference not set to an instance of an object. Stops when I change the reference part back to the command pod.

Not enough information, cannot reproduce the problem on the ground. (Or in space.) Saying the name of the exception is generally not at all as helpful as saying where it was caught.

Please post the full KSP_Data/output_log.txt

In my case, not only kethane but scansat, lazor, and probably more I don't remember/didn't discover, failed. It was pretty arbitrary which ones worked, as if it failing to load blocked the rest from loading properly.

Mechjeb actually does the same as Kethane -- and would choke on it just like Kethane, up until 2.1.1, possibly choking other things along the way.

Here's the kicker: one of the plugins that did load, and work correctly, was... Mechjeb.

Any clues here? What versions should it be working with?

SCANsat b5, MechJeb 2.1.1 (and has been tested with development builds).

My second request is for a special cameraTransform, ExtcamNext and ExtcamPrev.

No. That's because "ExtCam<number>" is just the default name for the camera transforms generated by the external camera selection module, but even these can generate transforms with different, unique names. Camera module has no clue they're even in order, and doesn't have any business doing it -- the reference transform is an exception because there's only one. This might be a function for JSISteerableCamera background handler, though, which would be able to go previous/next across arbitrary lists of cameras skipping over the absent ones, but you're not getting it this year.

With this comes the request to be able to get the current camera ID as a variable that we can then use to display it at the top of the screen.

Can't be done in the first place due to the pecuiliarities of the variable pipeline -- only one module actually knows anything about the variables, and that module has no idea which camera is current (or where -- there's only one variable computer per pod.)

Here's a example file to sort of demonstrate what I'm asking for. It basically shows how when the second menu is activated, button 1 is used to toggle the camera, but when the first menu is active it is used to display orbital characteristics. I'm not saying this is what I'd do with it, but hopefully it shows off what I'm asking for.

So basically you want page buttons to also have context-dependent functions, rather than just global buttons? Unfortunately in the current implementation it is impossible: The monitor itself doesn't know which button is which, buttons directly correspond to page objects, the ones generated by reading a PAGE {} block. It's going to take a lot more thinking to get around this without having to recode everything, and a naive syntax like you described won't work.

And lastly, the most horrendous request. Is it possible we could also get a _STAGE suffice for resource variables? Ie: FUEL_STAGE, FUEL_STAGE_MAX?

Maybe, but what about monopropellant and other global-flow resources? What should their _STAGE return?

[Hyomoto]

So basically you want page buttons to also have context-dependent functions, rather than just global buttons? Unfortunately in the current implementation it is impossible: The monitor itself doesn't know which button is which, buttons directly correspond to page objects, the ones generated by reading a PAGE {} block. It's going to take a lot more thinking to get around this without having to recode everything, and a naive syntax like you described won't work.

Maybe, but what about monopropellant and other global-flow resources? What should their _STAGE return?

As for the cameras, that seems like a bit of an oversight but it's pretty easy to overlook or work around with levels. As for gobal-flow resources, the answer which is simply, the same thing as they would return otherwise. The resources window does that, when you click 'stage only' it still shows the same number for electricity and monopropellant.

As for page levels, yes that is what I would like. As far as I can tell, each monitor knows at least two things; which buttons belong to it and what the last PAGE entry for that button was. Based on those two items, I'm really just suggesting you add one variable: the current page level for the monitor. Then, when you click a button you are adding two things, first whether or not this button matches the current page level, and two, whether or not this option changes the current page level. I may describe it badly, so here is a logic matrix. I assume the part above the blue line is what happens now, the part below is what I'm suggesting you add.

Edited December 28, 2013 by Hyomoto
Had to fix matrix. Whoops!

[Mihara]

As for the cameras, that seems like a bit of an oversight but it's pretty easy to overlook or work around with levels. As for gobal-flow resources, the answer which is simply, the same thing as they would return otherwise. The resources window does that, when you click 'stage only' it still shows the same number for electricity and monopropellant.

Ok, I'll see what I can do...

As for page levels, yes that is what I would like. As far as I can tell, each monitor knows at least two things; which buttons belong to it and what the last PAGE entry for that button was.

Nope. In fact, neither, because the buttons don't actually belong to the monitor. Pages know about the names of their own buttons, nothing else does. Once the button is pressed, the monitor gets a straight pointer to the page structure, information about the button is long gone by that point. A page might remember the name of the button it got by saving it during initialization, but currently it doesn't.

Buttons are pretty independent objects in Unity, (As a side note, stock IVA buttons, the ones that exist but mostly don't work, are fashioned in the same manner.) they are separate objects that are attached directly to the engine-maintained 3D objects and live their own lives. In the case of RPM, they store information in the form of direct pointers to page objects, which is what they send to the monitors when pressed. The structure you drew doesn't really work precisely for this reason -- a 'button' does not exactly 'have a page block'.

I do want to figure out some form of context dependent buttons, but it's not as easy in this particular case as you believe, because it wasn't designed for this from the outset.

P.S. I do have a half-decent idea, though, I can extend the locker/unlocker syntax.

Locker-unlocker syntax was made to support a "touch" screen where buttons were meant to be icons on the home screen, with the 'exit' button on it bringing the user back to root. Now, there's one interesting tidbit you probably didn't notice: The same button object can be both a globalButton and a page button. As long as the page button is ignored for whatever reason, the global button will take effect and be passed down to the handlers.

Now, it shouldn't be a problem to define more complicated locking/unlocking rules without breaking existent config file syntax (I do that too often as it is), the missing piece is how to translate numbered global button presses into calling other pages again.

Edited December 28, 2013 by Mihara

[Hyomoto]

I appreciate you taking the time to explain that, it makes much more sense why that wouldn't work then. Wow, so yeah, that really wouldn't work then. I'm glad you have an idea already, nothing easy pops to mind when you put it that way. Is it possible to use a pointer to the rasterprop for the button to query who it "belongs" to? I'm sure you've already thought of this stuff if you've come this far, so it's fair to trust your judgement and expertise.

I'm glad you've taken the time to do this, perhaps this will help Squad realize how much fun IVA is to play in ... when you have to tools to do so. The working buttons on the console, the useful lights and your raster prop just makes it a joy to do IVA. I'm working on a series of IVA-only missions, and it's a bit like starting KSP all over again!

[Mihara]

I appreciate you taking the time to explain that, it makes much more sense why that wouldn't work then. Wow, so yeah, that really wouldn't work then. I'm glad you have an idea already, nothing easy pops to mind when you put it that way. Is it possible to use a pointer to the rasterprop for the button to query who it "belongs" to?

For the button - no. The button doesn't have that pointer, because it might not even be located on it's prop, but somewhere else entirely. In fact, all the other modules in the system use the very same button class, being a button that calls the things that were specified during it's creation is essentially a generic function of a 3D object.

I think I'll end up with 'locking' page parameter being extended to name (in one way or another) pages which must not be switched to while this page is active, and a sort of 'global button to page' block which would list pairs of what page should get triggered if a certain global button comes in.

Then you will be able to define every button as both a page button and a global button, which will make it possible to arbitrarily redefine the function of every button while a certain page is active. It's a bit crude, but it will at least work fine.

I'm working on a series of IVA-only missions, and it's a bit like starting KSP all over again!

Make it a video series.

[dRuPpI]

This is a Kethane problem that can be triggered by any mod which includes a plugin that fails to load. Unfortunately, sometimes they're supposed to fail to load.

Kethane searches the other plugins for functions implementing it's API so that the API can actually happen. Unfortunately, the plugin that failed to load also gets found, but then cannot be accessed and Kethane chokes on it. The solution at the moment is looking diligently through the debug log for a plugin that generates an AssemblyLoader exception ("AssemblyLoader: Exception loading thatplugin") and making sure it is updated or failing that, removed.

If you use RPM but do not use SCANsat, SCANsatRPM.dll will fail to load (as intended) and trigger this bug. If you use RPM but do not use MechJeb, MechJebRPM.dll will fail to load (as intended!) and trigger this bug. The same will happen with any plugins that optionally use the Toolbar when the toolbar itself is not installed -- this requires them to bundle a separate plugin which they use to communicate with the toolbar, which will fail to load if the toolbar is not installed.

Majir seems to have fixed it, but he isn't treating releasing the fixed version as a matter of urgency, so you can either install MechJeb and SCANsat or remove MechJebRPM.dll/SCANsatRPM.dll.

ok thanks, with out the MechRPM and ScansatRPM dlls it seams to work now again. Hopefully Majir will release the fix soon

[dRuPpI]

For the button - no. The button doesn't have that pointer, because it might not even be located on it's prop, but somewhere else entirely. In fact, all the other modules in the system use the very same button class, being a button that calls the things that were specified during it's creation is essentially a generic function of a 3D object.

I think I'll end up with 'locking' page parameter being extended to name (in one way or another) pages which must not be switched to while this page is active, and a sort of 'global button to page' block which would list pairs of what page should get triggered if a certain global button comes in.

Then you will be able to define every button as both a page button and a global button, which will make it possible to arbitrarily redefine the function of every button while a certain page is active. It's a bit crude, but it will at least work fine.

Make it a video series.

Yeah make it

[mrfox]

Another request for an additional variable please.

Horizontal surface velocity, split into lateral and longitudinal components along the aircraft/spacecraft axis. Looking to create a display for precision hovering/vertical landing, in place of the navball vector display that gets very twitchy near zero vertical speed.

Many thanks again!

[Mihara]

I appreciate you taking the time to explain that, it makes much more sense why that wouldn't work then.

Ok, I think I'm done with a preliminary implementation of what will work. Check the dev version and see the wiki for the updated documentation. (Configuring a monitor is the page you want) Tell me if that is sufficient for making a monitor you want or if there's something serious missing.

Horizontal surface velocity, split into lateral and longitudinal components along the aircraft/spacecraft axis.

No problem at all, but you need to explain to me what 'lateral' and 'longitudinal' means, because I don't know. I did say I barely, if at all, understand any of the mathematics involved.

[SergeantBlueforce]

Could you make a 0.23 version that doesn't re-arrange the stock IVAs?

[Mihara]

Could you make a 0.23 version that doesn't re-arrange the stock IVAs?

If you want one, you use old ModuleManager patches from previous releases, they still work -- but I won't be making a new one since there's no reasonable way to select between them within the package.

If you just don't want it to touch the stock IVAs but want RPM to play with other capsules, well, just delete the modulemanager patches that patch the new IVAs into them.

[mrfox]

No problem at all, but you need to explain to me what 'lateral' and 'longitudinal' means, because I don't know. I did say I barely, if at all, understand any of the mathematics involved.

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)

As implemented in the Apollo LEM:

If the needles are centered, you are in a stationary hover.

Edited December 29, 2013 by mrfox