Jump to content

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


Mihara

Recommended Posts

Short answer, no. Longer answer, I would have to introduce a hard dependency on AGX to support additional custom actions using the custom## format, which would force people to install AGX to use RPM. It is probably possible to create a "AGXRPM.dll", similar to the MechJebRPM.dll, that would make it possible to use those additional action groups, but I don't have time to for that.

We support all of the AGX action groups in kOS if it is installed with no hard dependency

https://github.com/KSP-KOS/KOS/tree/develop/src/kOS/AddOns/ActionGroupsExtended

it was a little bit of work but we are GPL3 if you want to use that code to build your own interop with AGX

Link to comment
Share on other sites

We support all of the AGX action groups in kOS if it is installed with no hard dependency

https://github.com/KSP-KOS/KOS/tree/develop/src/kOS/AddOns/ActionGroupsExtended

it was a little bit of work but we are GPL3 if you want to use that code to build your own interop with AGX

Not to mention that AGX author Diazo is usually very helpful in integrating other mods with his, so you may not be doing it all yourself

Link to comment
Share on other sites

Not to mention that AGX author Diazo is usually very helpful in integrating other mods with his, so you may not be doing it all yourself

That is very true. He even wrote our documentation on the integration. Very helpful and thoughtful contributor. Would pull from again :)

Link to comment
Share on other sites

@MOARdV

On another note, is it possible to capture fuel levels when using Nathan Kell's 'real fuels' mod. As soon as I use real fuels, the liquid fuel gauges stop working (for obvious reasons). Does real fuels introduce new variable names, and if so, what are they?

Your kindness in responding is noticed and appreciated! :)

Link to comment
Share on other sites

@MOARdV

On another note, is it possible to capture fuel levels when using Nathan Kell's 'real fuels' mod. As soon as I use real fuels, the liquid fuel gauges stop working (for obvious reasons). Does real fuels introduce new variable names, and if so, what are they?

Your kindness in responding is noticed and appreciated! :)

Yes, Real Fuels uses different resource names. Fortunately, Mihara made RPM smart enough that it can figure out the resource names, even if they're new resources. They're going to be named SYSR_(whatever the resource is named). If debug logging is enabled in RPM (by default it is), you should be able to search through KSP.log to find some entries like "Remembering system resource (something) as SYSR_(somethingelse)". You'll have to edit your page definition files to replace SYSR_LIQUIDFUEL and SYSR_OXIDIZER with the appropriate SYSR_(somethingelse) names.

Link to comment
Share on other sites

MOARdV, did you manage to reproduce that black HUD OpenGL bug? As others have previously said, alt-tabbing during loading or at main menu fixes the 3/4 black screen bug, allowing you to play the game normally.

The only issue I have is that black hud thing. By hud I mean the alternate screen to the navball, and the B9 internal camera nav screens. The text shows up ok, but the all the stuff that comes from the JSI\RasterPropMonitor\Library\Components\HUD *.png files is black. It seems to read transparency, but not color.

The actual plane physical HUD of some planes should show up, with black lines and numbers surrounded by a green outline. It's not a new problem, by a long shot. I noticed it almost one year ago but back then I wasn't doing IVA-only and B9 didn't have those awesome new cockpits :D This is on Windows 8 64 bit (but 32bit Kerbal, otherwise I wouldn't need OpenGL :D). This bug appears on a clean install with nothing but RPM installed.

Link to comment
Share on other sites

MOARdV, did you manage to reproduce that black HUD OpenGL bug? As others have previously said, alt-tabbing during loading or at main menu fixes the 3/4 black screen bug, allowing you to play the game normally.

Okay, I tried it with the alt-tab trick, and that gets me into the game. I see the black with OpenGL, but I also see white showing up with DirectX. It's not as pronounced, but it's still visible. There's a lot of aliasing problems - I don't know if that's because of the HUD's render target or the textures being used, or what. The problem may be the shader that the HUD is using. I know Mihara had mentioned more than once wanting custom shaders, but I didn't know how to do them at that time. In any case, since the behavior is different depending on the renderer used, it's probably not going to be trivial for me to work around it. I'll see what I can do, but no promises on when it'll happen.

Link to comment
Share on other sites

I've done some testing, moving the HUD pngs to other pages (for example exchanging the Navball background file with the hud one), the colors load up correctly, moving other pngs to the hud page (black again). I've tried every type of Color mode by editing them in Photoshop. I've tried replacing them with TGAs with alpha channels. Results were the same. It seems that renderHud method reads transparency, but not color information.

Link to comment
Share on other sites

I've done some testing, moving the HUD pngs to other pages (for example exchanging the Navball background file with the hud one), the colors load up correctly, moving other pngs to the hud page (black again). I've tried every type of Color mode by editing them in Photoshop. I've tried replacing them with TGAs with alpha channels. Results were the same. It seems that renderHud method reads transparency, but not color information.

I strongly suspect the problem is the shader in question - it's a "Hidden" shader, according to its name. I suspect that I'll ultimately have to write a custom shader for the HUD, which means it'll be a while before I can fix it. Too many things going on IRL right now to focus on that.

Link to comment
Share on other sites

I have had a problem that occurs when either RPM or Firespitter dlls are installed, I made a thread here,

http://forum.kerbalspaceprogram.com/threads/109974-No-staging-commands-unable-to-do-anything?p=1726238

It occurs when RPM is installed, same with firespitter

Without the output_log.txt, there's not much I can specifically do - it looks like a problem related to missing IVAs. If you start a session and get to the launch pad with a craft that demonstrates this problem, and then revert / exit and upload KSP_Data/output_log.txt, I'll see if I can find some clues.

Link to comment
Share on other sites

[PlanetariumCamera]: Focus: FASA Gemini Titan III-C MOL

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

[FASA Gemini Titan III-C MOL]: ground contact! - error: 0.037m

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

Unpacking FASA Gemini Titan III-C MOL

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

NullReferenceException

at (wrapper managed-to-native) UnityEngine.MeshFilter:set_sharedMesh (UnityEngine.Mesh)

at SpriteMesh.CreateMesh () [0x00000] in <filename unknown>:0

at SpriteMesh.get_mesh () [0x00000] in <filename unknown>:0

at SpriteRoot.Delete () [0x00000] in <filename unknown>:0

at SpriteBase.Delete () [0x00000] in <filename unknown>:0

at UIListItemContainer.Delete () [0x00000] in <filename unknown>:0

at UIScrollList.RemoveItem (Int32 index, Boolean destroy, Boolean doEasing) [0x00000] in <filename unknown>:0

at UIScrollList.RemoveItem (IUIListObject item, Boolean destroy, Boolean doEasing) [0x00000] in <filename unknown>:0

at UIScrollList.RemoveItem (IUIListObject item, Boolean destroy) [0x00000] in <filename unknown>:0

at ApplicationLauncher.RemoveApplication (.ApplicationLauncherButton button) [0x00000] in <filename unknown>:0

at ResourceDisplay.OnDestroy () [0x00000] in <filename unknown>:0

(Filename: Line: -1)

NullReferenceException: Object reference not set to an instance of an object

at Versioning.get_version_major () [0x00000] in <filename unknown>:0

at RealChute.CompatibilityChecker.IsCompatible () [0x00000] in <filename unknown>:0

at RealChute.CompatibilityChecker.IsAllCompatible () [0x00000] in <filename unknown>:0

at RealChute.RealChuteModule.OnDestroy () [0x00000] in <filename unknown>:0

(Filename: Line: -1)

NullReferenceException: Object reference not set to an instance of an object

at Versioning.get_version_major () [0x00000] in <filename unknown>:0

at RealChute.CompatibilityChecker.IsCompatible () [0x00000] in <filename unknown>:0

at RealChute.CompatibilityChecker.IsAllCompatible () [0x00000] in <filename unknown>:0

at RealChute.RealChuteModule.OnDestroy () [0x00000] in <filename unknown>:0

(Filename: Line: -1)

NullReferenceException: Object reference not set to an instance of an object

at ThrottleControlledAvionics.TCAConfiguration.SaveConfigs (.ConfigNode node) [0x00000] in <filename unknown>:0

at ThrottleControlledAvionics.TCAConfiguration.Save (System.String configs) [0x00000] in <filename unknown>:0

at ThrottleControlledAvionics.TCAConfiguration.Save () [0x00000] in <filename unknown>:0

at ThrottleControlledAvionics.ThrottleControlledAvionics.OnDestroy () [0x00000] in <filename unknown>:0

(Filename: Line: -1)

NullReferenceException

at (wrapper managed-to-native) UnityEngine.Component:InternalGetGameObject ()

at UnityEngine.Component.get_gameObject () [0x00000] in <filename unknown>:0

at MapView.OnDestroy () [0x00000] in <filename unknown>:0

(Filename: Line: -1)

Link to comment
Share on other sites

Installed the patch for SP+ parts. When I would use an MK2 cockpit, it wouldn't show that there were any crew in it, I couldn't go IVA, and I had no control of the vehicle. It was like I had put an empty cockpit out there, even though I made sure I had crew. All other capsules and cockpits worked fine. Removed the patch and everything was back to normal, with no MFDs in the MK2

Link to comment
Share on other sites

Wont let me do attatchments

You'll need to use something like DropBox or some other method to post the entire log, since there's nothing in that snippet pointing at RasterPropMonitor.

Installed the patch for SP+ parts. When I would use an MK2 cockpit, it wouldn't show that there were any crew in it, I couldn't go IVA, and I had no control of the vehicle. It was like I had put an empty cockpit out there, even though I made sure I had crew. All other capsules and cockpits worked fine. Removed the patch and everything was back to normal, with no MFDs in the MK2

It might be that the patch for the SP+ parts needs updated. It's not part of the RPM distribution, so you might need to track down whoever made the patch and see if there's an update.

Link to comment
Share on other sites

  • 2 weeks later...
Guest
This topic is now closed to further replies.
×
×
  • Create New...