Jump to content

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

Mihara

By Mihara
in KSP1 Mod Releases

 Share

Recommended Posts

royying

royying

Posted
Posted

The 0.16's external camera has a black mark on top, it helps me identify the orientation of the camera, prevent the display become upside down. I found out the 0.17's external camera has no black mark on it, can you add it back?

Link to comment
Share on other sites
Mihara

Mihara

Posted
  • Author
Posted
The 0.16's external camera has a black mark on top, it helps me identify the orientation of the camera, prevent the display become upside down. I found out the 0.17's external camera has no black mark on it, can you add it back?

Oops, I messed up when editing the part config for it. The texture is actually there, it just isn't getting applied.

Replace 'external-camera.cfg' with this one for now, the next version will have that fixed.

Link to comment
Share on other sites
Mihara

Mihara

Posted
  • Author
Posted
ok, on your advice, I completely removed the KSO, RPM and mechjeb, then reinstalled the latest versions of the KSO and MJ, as well as .16 RPM. Unfortunately, I'm still getting the same error.

Um... Er... whyfor did you install .16 after that?... Latest KSO should be normally compatible with RPM 0.17, I tested it... Ok, let's make this clear:

RPM v0.16 requires that:

  1. MechJeb version is 2.2.1 release OR MechJebRPM.dll is deleted. (in which case, MechJeb will not be interfaced to.)
  2. SCANsat is version 5 OR SCANsatRPM.dll is deleted (in which case SCANsat will not be interfaced to) OR SCANsat version 6 is used with SCANsatRPM.dll that came from that SCANsat version 6 package.

RPM v0.17 requires that:

  1. MechJeb dev version with build number 254 or greater is used, OR MechJebRPM.dll is deleted, (in which case, MechJeb will not be interfaced to.) OR MechJeb is not present in the installation. (Which will now be handled correctly for every subsequent version of MechJeb finally)
  2. SCANsat version 6 is used with SCANsatRPM.dll that came with RPM OR SCANsat version 7 is used with SCANsatRPM.dll that came with RPM, (well, it should work, but I haven't tested it yet) OR SCANsatRPM.dll is deleted (in which case SCANsat will not be interfaced to). (Unfortunately SCANsat not being present on the system at all can still cause problems, the reason for which takes a long rant to describe.)

Since current KSO does not reference any textures or models that come with RPM, and does not use any of the features new to 0.17, it should work with either 0.16 or 0.17, provided the above conditions are satisfied.

Link to comment
Share on other sites
Capt. Hunt

Capt. Hunt

Posted
Posted

ok, I'll try .17. Earlier, you did recommend not using .17 yet because it wasn't as stable as .16.

I hadn't thought about scansat, I don't remember what version of that I'm using, I'll update it.

I think the root of the problem is that KSO appears to be bundled with RPM .16, If my MJ and Scansat installs weren't up to date that would explain why it caused the problem.

Also, I just noticed that the version number of MM that came with your mod is newer then the one I had installed, I swapped that out.

Let's see what happens.

Link to comment
Share on other sites
Horus

Horus

Posted
Posted (edited)

SCANSat 7 has some issues with RPM:

1. When scansat launched on a central monitor (tested on Mk1 Lander Can) - you cannot switch modes on the other monitors.

2. Same situation and when coming from a save - the other monitors show "gray-something".

Both situations are fixed by switching central monitor to some other RPM data (not scan sat)

3. Scanned area not dispayed on scansat rpm monitor.

I'd suggest to stay on stable SCANSat 6 for now (with Mihara's recent scansat rpm).

Edited by Horus
typo
Link to comment
Share on other sites
Mihara

Mihara

Posted
  • Author
Posted
ok, I'll try .17. Earlier, you did recommend not using .17 yet because it wasn't as stable as .16.

I didn't say it wasn't stable. I try not to call unstable builds 'release'. :) However, it involves changes in the distribution structure -- the most important of which is that MechJebRPM.dll can now be stored where it should have been from the start, and that the monitor model that previously came with RPM was removed. (Because it has broken colliders.) Most IVAs that say 'uses RasterPropMonitor' actually rely on that old model, and thus will be broken by the installation of RPM 0.17 until they are appropriately edited.

Current release of KSO, however, has it's own models for every monitor, so this change does not affect KSO at all.

SCANSat 7 has some issues with RPM

Well, I guess by the time SCANsat 7 is actually released, SCANsatRPM is properly integrated into SCANsat, and then the problem will be gone for good and like VesselView, SCANsat will continue working with RPM in perpetuity until Squad does something to kill either of them. :)

Link to comment
Share on other sites
DMagic

DMagic

Posted
Posted

Anyone using SCANsat v7 should be using the latest dev build, version 7 rc 2.5 (which hasn't actually been added to the first post). Do note the instructions however, the folder structure has been changed so you should delete any old versions.

It was updated to explicitly support RPM v.17. I also added the KSPAssembly and KSPAssemblyDependency lines so it should be a little less picky about file locations.

Whenever I get a chance I'll look through Mihara's SCANsatRPM pull more carefully to see about getting everything working right in a single .dll.

Link to comment
Share on other sites
Vladthemad

Vladthemad

Posted
Posted

Great mod, I've loved *trying* to use it....not always successful at understanding the the deluge information being provided ;) With the addition of the autopilot/mechjeb integration, I'd like to know if there is a way to add mechjeb via module manager to only pods that contain RPMs? I know that with "@part[*]:has[@module[modulecommand]]:final" I can add mechjeb to all pods with command modules, but is there a module in the configs that represents RPM's that module manager can locate? I didn't spot any in the configs for ASET or KSO parts...but I'm not sure where I should be looking.

Link to comment
Share on other sites
Mecripp

Mecripp

Posted
Posted
Great mod, I've loved *trying* to use it....not always successful at understanding the the deluge information being provided ;) With the addition of the autopilot/mechjeb integration, I'd like to know if there is a way to add mechjeb via module manager to only pods that contain RPMs? I know that with "@part[*]:has[@module[modulecommand]]:final" I can add mechjeb to all pods with command modules, but is there a module in the configs that represents RPM's that module manager can locate? I didn't spot any in the configs for ASET or KSO parts...but I'm not sure where I should be looking.

You might try

@PART[*]:HAS[@MODULE[RasterPropMonitor],!MODULE[MechJebCore]]]

{

MODULE

{

name = MechJebCore

}

}

not test but should work.
Link to comment
Share on other sites
Mihara

Mihara

Posted
  • Author
Posted
You might try not test but should work.

Not quite. :)


@PART[*]:HAS[@MODULE[RasterPropMonitorComputer],!MODULE[MechJebCore]]:Final
{
    MODULE
    {
	    name = MechJebCore
        MechJebLocalSettings {
            MechJebModuleCustomWindowEditor { unlockTechs = flightControl }
            MechJebModuleSmartASS { unlockTechs = flightControl }
            MechJebModuleManeuverPlanner { unlockTechs = advFlightControl }
            MechJebModuleNodeEditor { unlockTechs = advFlightControl }
            MechJebModuleTranslatron { unlockTechs = advFlightControl }
            MechJebModuleWarpHelper { unlockTechs = advFlightControl }
            MechJebModuleAttitudeAdjustment { unlockTechs = advFlightControl }
            MechJebModuleThrustWindow { unlockTechs = advFlightControl }
            MechJebModuleRCSBalancerWindow { unlockTechs = advFlightControl }
            MechJebModuleRoverWindow { unlockTechs = fieldScience }
            MechJebModuleAscentGuidance { unlockTechs = unmannedTech }
            MechJebModuleLandingGuidance { unlockTechs = unmannedTech }
            MechJebModuleSpaceplaneGuidance { unlockTechs = unmannedTech }
            MechJebModuleDockingGuidance { unlockTechs = advUnmanned }
            MechJebModuleRendezvousAutopilotWindow { unlockTechs = advUnmanned }
            MechJebModuleRendezvousGuidance { unlockTechs = advUnmanned }
        }
    }
}

Link to comment
Share on other sites
kujuman

kujuman

Posted
Posted

First off, I'd like to thank you for not only developing and maintaining a great mod, but providing such helpful documentation in the wiki.

With that said, I figured I'd show off a plugin I've gotten back into the swing of developing that provides a horizontal situation indicator to allow for instrument landings from the pit. Developing it for RPM was a steep learning curve (the worst part was figuring out how to work with RenderTextures) but thanks to the wiki it was relatively simple once I cleared that first hurdle.

vRBvVSJl.png

Link to comment
Share on other sites
Mihara

Mihara

Posted
  • Author
Posted
First off, I'd like to thank you for not only developing and maintaining a great mod, but providing such helpful documentation in the wiki.

With that said, I figured I'd show off a plugin I've gotten back into the swing of developing that provides a horizontal situation indicator to allow for instrument landings from the pit. Developing it for RPM was a steep learning curve (the worst part was figuring out how to work with RenderTextures) but thanks to the wiki it was relatively simple once I cleared that first hurdle.

That looks sweet! More plugins for RPM that use the RPM API are always nice, because I don't have to worry about breaking them. :)

Link to comment
Share on other sites
hcalves

hcalves

Posted
Posted (edited)

I see the FoV cones for the pit cameras on the VAB, but how do you reposition / rotate them?

EDIT: Nevermind, figured out Space Plane Plus pit adds some fixed cameras of it's own.

Edited by hcalves
Link to comment
Share on other sites
Mihara

Mihara

Posted
  • Author
Posted
hey Mihara, there is no way to make the HeadingBar alpha channel of the JSIPrimaryFlightDisplay behave like in JSIHeadsUpDisplay?

If I set background to be transparent, headingbar disapears...

The HeadingBar is actually a picture of a mesh in space, and the shader on that mesh is "KSP/Alpha/Unlit Transparent", so transparency should work. Check your alpha layer? Preferably in Unity on an actual box with that shader on it.

Link to comment
Share on other sites
Mihara

Mihara

Posted
  • Author
Posted
Is there any way for us users to easily ix the monitor problem that arose with 0.17 or do we have to wait for the mods creator to update his mod....

Depends on how easy is easy.

  1. IVAs that used only the example monitor and props as is just need a search-replace of 'RasterPropMonitorExampleMFD' to 'RasterPropMonitorBasicMFD' and 'IndicatorPanel' to 'IndicatorPanelRPM' in their internal.cfg
  2. More complex IVA setups have their own monitor configs. In those:
    • Files that were in RasterPropMonitor/Example now live in RasterPropMonitor/Library, sorted based on what they are. Their names did not change, but paths did, so you'd need to find the new location and change it, everywhere RPM configuration refers to actual files.
    • The number and arrangement of buttons on the new MFD model is different, the old model is gone (hopefully for good because broken colliders are probably responsible for at least a quarter of 'RPM lags!' statements) so if the IVA used the old MFD model, it's prop file needs the new model instead, and pages may need a more in-depth changes.

Check https://github.com/Mihara/RasterPropMonitor/wiki/Distribution-notes for what is where.

Link to comment
Share on other sites
DasBananenbrot

DasBananenbrot

Posted
Posted
Depends on how easy is easy.

  1. IVAs that used only the example monitor and props as is just need a search-replace of 'RasterPropMonitorExampleMFD' to 'RasterPropMonitorBasicMFD' and 'IndicatorPanel' to 'IndicatorPanelRPM' in their internal.cfg
  2. More complex IVA setups have their own monitor configs. In those:
    • Files that were in RasterPropMonitor/Example now live in RasterPropMonitor/Library, sorted based on what they are. Their names did not change, but paths did, so you'd need to find the new location and change it, everywhere RPM configuration refers to actual files.
    • The number and arrangement of buttons on the new MFD model is different, the old model is gone (hopefully for good because broken colliders are probably responsible for at least a quarter of 'RPM lags!' statements) so if the IVA used the old MFD model, it's prop file needs the new model instead, and pages may need a more in-depth changes.

Check https://github.com/Mihara/RasterPropMonitor/wiki/Distribution-notes for what is where.

Well, you are right easy is relative :D But with your idiot-proof documentation , it is pretty easy. (provided one can read :wink: )

Link to comment
Share on other sites
luizopiloto

luizopiloto

Posted
Posted (edited)
The HeadingBar is actually a picture of a mesh in space, and the shader on that mesh is "KSP/Alpha/Unlit Transparent", so transparency should work. Check your alpha layer? Preferably in Unity on an actual box with that shader on it.

texture's Alpha channel is ok... im designing a Hud, with a NavBall page. On the Hud, HeadingBar shows nicelly, but on Navball page it gets the same opacity as the background color property... witch is 10. Same as set in Hud page... "backgroundColor = 0,102,0,10"

If I set background opacity to 255, or whatever more opaque :P, heading bar gets pretty visible.. like in the Hud page. If set to lower values it becames barelly visible. Even the overlay part that is outside the navball gets transparent/translucid.

I also tested it with default textures, same thing happens.http://i.imgur.com/s7XC0tk.png http://i.imgur.com/dMmmzln.png

Edited by luizopiloto
Link to comment
Share on other sites
Vladthemad

Vladthemad

Posted
Posted
Not quite. :)


@PART[*]:HAS[@MODULE[RasterPropMonitorComputer],!MODULE[MechJebCore]]:Final
{
    MODULE
    {
	    name = MechJebCore
        MechJebLocalSettings {
            MechJebModuleCustomWindowEditor { unlockTechs = flightControl }
            MechJebModuleSmartASS { unlockTechs = flightControl }
            MechJebModuleManeuverPlanner { unlockTechs = advFlightControl }
            MechJebModuleNodeEditor { unlockTechs = advFlightControl }
            MechJebModuleTranslatron { unlockTechs = advFlightControl }
            MechJebModuleWarpHelper { unlockTechs = advFlightControl }
            MechJebModuleAttitudeAdjustment { unlockTechs = advFlightControl }
            MechJebModuleThrustWindow { unlockTechs = advFlightControl }
            MechJebModuleRCSBalancerWindow { unlockTechs = advFlightControl }
            MechJebModuleRoverWindow { unlockTechs = fieldScience }
            MechJebModuleAscentGuidance { unlockTechs = unmannedTech }
            MechJebModuleLandingGuidance { unlockTechs = unmannedTech }
            MechJebModuleSpaceplaneGuidance { unlockTechs = unmannedTech }
            MechJebModuleDockingGuidance { unlockTechs = advUnmanned }
            MechJebModuleRendezvousAutopilotWindow { unlockTechs = advUnmanned }
            MechJebModuleRendezvousGuidance { unlockTechs = advUnmanned }
        }
    }
}

Hah, I was just coming on to say that I figured it out after spending some time digging through all the configs, but you beat me to the punch. :D

Link to comment
Share on other sites
Mihara

Mihara

Posted
  • Author
Posted
texture's Alpha channel is ok... im designing a Hud, with a NavBall page. On the Hud, HeadingBar shows nicelly, but on Navball page it gets the same opacity as the background color property... witch is 10. Same as set in Hud page... "backgroundColor = 0,102,0,10"

If I set background opacity to 255, or whatever more opaque :P, heading bar gets pretty visible.. like in the Hud page. If set to lower values it becames barelly visible. Even the overlay part that is outside the navball gets transparent/translucid.

I also tested it with default textures, same thing happens.http://i.imgur.com/s7XC0tk.png http://i.imgur.com/dMmmzln.png

Navball and HUD work completely differently. HUD actually draws on a texture. Navball is a camera rendering of an actual model that is hidden somewhere within the IVA world. (That's why, sometimes when you timewarp, navball will show differently). All the overlays which compose the navball page are taken in during the same camera snapshot and are drawn in the world with a different set of shaders from the shaders the HUD uses. So what works for HUD does not necessarily work for the navball.

You probably need different variants of the heading bar for them.

Link to comment
Share on other sites
Tinweasele

Tinweasele

Posted
Posted

Hey all, Im looking into the RastorPropManager Initialization failure when attempting to load up probe control room.(requires SCANSAT). What is the error usually indicitive of? Im fairly good with hunting down issues.. but the error is KINDA vague:-)

Any help is appreciated.

Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...