Jump to content

[1.6.x] RasterPropMonitor - Development Stopped (v0.30.6, 29 December 2018)

MOARdV

By MOARdV
in KSP1 Mod Releases

 Share

Recommended Posts

MOARdV

MOARdV

Posted
  • Author
Posted

I've updated the RPM v0.23.0 dev build on DropBox. New feature: custom math variables, along with constants for meters to feet and m/s to knots (take a look at the custom variables page on the RPM wiki for more info on the math variables).

How would I go about fixing that then =/

Under GameData in your KSP install, find JSI/RPMPodPatches/BasicMFD/MFD40x20.cfg. Open that in a text editor and search for "JSIPrimaryFlightDisplay". Copy that entire section (from the line above that one that says "BACKGROUNDHANDLER" to the first closing curly brace '}' after it). Go to the config file for the props in NFT. I think it's NearFutureProps/Props/Screens/NFTMFD/nft_MFD_Large_Type1.cfg, but I don't know for sure. In that file, find the JSIPrimaryFlightDisplay BACKGROUNDHANDLER, and replace it. Oh yeah, and back up the file beforehand. If that doesn't work, you can check with Nertea or someone in the NFT thread to see which prop or props use the primary flight display and the HUD features from RPM.

Link to comment
Share on other sites
Diddly Feelerino

Diddly Feelerino

Posted
Posted
I've updated the RPM v0.23.0 dev build on DropBox. New feature: custom math variables, along with constants for meters to feet and m/s to knots (take a look at the custom variables page on the RPM wiki for more info on the math variables).

Under GameData in your KSP install, find JSI/RPMPodPatches/BasicMFD/MFD40x20.cfg. Open that in a text editor and search for "JSIPrimaryFlightDisplay". Copy that entire section (from the line above that one that says "BACKGROUNDHANDLER" to the first closing curly brace '}' after it). Go to the config file for the props in NFT. I think it's NearFutureProps/Props/Screens/NFTMFD/nft_MFD_Large_Type1.cfg, but I don't know for sure. In that file, find the JSIPrimaryFlightDisplay BACKGROUNDHANDLER, and replace it. Oh yeah, and back up the file beforehand. If that doesn't work, you can check with Nertea or someone in the NFT thread to see which prop or props use the primary flight display and the HUD features from RPM.

Thanks for the help; we have some progress but not quite there yet.....

Any idea how to fix this? =P

screenshot151.png

Link to comment
Share on other sites
MOARdV

MOARdV

Posted
  • Author
Posted

I've updated the dev build on DropBox to fix a couple of derps in the new feature code. Thanks to DeputyLOL for finding those so quickly.

Any idea how to fix this? =P

Yes.

Oh, I was supposed to answer that? There are entries in the background handler that look like this:


navBallCenter = 320,302

headingBarPosition = 320, 22, 128, 18

The first number on each (320) needs to be changed to move the navball and heading bar to the right. You will need to look in the config file, near the top, for 


screenPixelWidth = (something)

Where (something) is a number. Change both "320"s in the PFD to half of "something". That should center the ball and heading strip on the screen. You can also tweak that number to move it around (the 320, 302 are the x,y coordinate of the center of the ball).

Link to comment
Share on other sites
Adyx

Adyx

Posted
Posted

The black screen in the HUD can be fixed by placing ladder.png from an older version of RPM into \GameData\JSI\RasterPropMonitor\Library\Components\HUD. In current versions of RPM only ladder.dds is present. I presume this is by design since other HUD elements are also only in dds format but it seems in certain circumstances (graphics settings maybe?) ladder.png is required despite the other HUD elements working fine in dds format.

Link to comment
Share on other sites
MOARdV

MOARdV

Posted
  • Author
Posted
The black screen in the HUD can be fixed by placing ladder.png from an older version of RPM into \GameData\JSI\RasterPropMonitor\Library\Components\HUD. In current versions of RPM only ladder.dds is present. I presume this is by design since other HUD elements are also only in dds format but it seems in certain circumstances (graphics settings maybe?) ladder.png is required despite the other HUD elements working fine in dds format.

I have updated the dev build on DropBox with a slightly different ladder.dds. If someone having this black ladder problem could test out the new version and see if it works (making sure the old ladder.png is not there), I would appreciate it. If it is still a problem even after this change, I will revert ladder.dds to a different format.

Link to comment
Share on other sites
Adyx

Adyx

Posted
Posted
I have updated the dev build on DropBox with a slightly different ladder.dds. If someone having this black ladder problem could test out the new version and see if it works (making sure the old ladder.png is not there), I would appreciate it. If it is still a problem even after this change, I will revert ladder.dds to a different format.

That seems to have done it. I completely removed the JSI folder and installed that dev build and no more black screen on the HUD. Thanks! Now I just have to fix the ASET and MkIV PFD navballs. Thanks also for the above instructions.

Link to comment
Share on other sites
anxcon

anxcon

Posted
Posted

for the partmodule JSITransparentPod, to see an IVA from outside, what parts / part packs do i need to get?

tried applying to stock pods/cockpits, and several of the mods i have installed, but none seem to work

Link to comment
Share on other sites
MOARdV

MOARdV

Posted
  • Author
Posted
for the partmodule JSITransparentPod, to see an IVA from outside, what parts / part packs do i need to get?

tried applying to stock pods/cockpits, and several of the mods i have installed, but none seem to work

You need a pod that specifically supports the JSITransparentPod feature. The work-in-progress experimental version of the SDHI / FusTek station parts supports it (or did), and I think one or two Bobcat pods did (but I don't think they've been updated to KSP 1.x). I want to say that Alexustas has a rover that does, as well. I don't know of any other current parts that support it.

Link to comment
Share on other sites
anxcon

anxcon

Posted
Posted
You need a pod that specifically supports the JSITransparentPod feature. The work-in-progress experimental version of the SDHI / FusTek station parts supports it (or did), and I think one or two Bobcat pods did (but I don't think they've been updated to KSP 1.x). I want to say that Alexustas has a rover that does, as well. I don't know of any other current parts that support it.

how much effort is it (for someone who knows how to model, but never touched unity) to edit the models to make em compatible?

Link to comment
Share on other sites
MOARdV

MOARdV

Posted
  • Author
Posted
how much effort is it (for someone who knows how to model, but never touched unity) to edit the models to make em compatible?

The transparency code is entirely Mihara's creation, and it happened during my hiatus from KSP last year. Outside of the notes on the transparency GitHub page, I can't really provide much advice. Sumghai has worked with making parts for the module recently, and he may be able to provide more insight from a modeler's perspective. Be forewarned that frame rates drop sharply when there's more than one or two transparent modules in play, so it should be used sparingly.

Link to comment
Share on other sites
anxcon

anxcon

Posted
Posted
Be forewarned that frame rates drop sharply when there's more than one or two transparent modules in play, so it should be used sparingly.

on that note had a thought, perhaps the partmodule JSITransparentPod add a button to toggle the IVA view on/off, then large ships could potentially have all turned on just for screenshots etc, or cases of docking ships etc can disable the unneeded extras

or hell a step further and button has a mode for 'auto' to activat the view only if 'control from here' from modulecommand is active, then stations/bases with spread out stuff (like manufacturing) using modulecommand to control part focus could have all the places set to auto, but only one would ever really be active

Link to comment
Share on other sites
MOARdV

MOARdV

Posted
  • Author
Posted
on that note had a thought, perhaps the partmodule JSITransparentPod add a button to toggle the IVA view on/off, then large ships could potentially have all turned on just for screenshots etc, or cases of docking ships etc can disable the unneeded extras

or hell a step further and button has a mode for 'auto' to activat the view only if 'control from here' from modulecommand is active, then stations/bases with spread out stuff (like manufacturing) using modulecommand to control part focus could have all the places set to auto, but only one would ever really be active

That would be a solution. Since it's a part module, it'd be easy to add options to the right-click menu to provide control of the behavior.

Alright

Tried a fresh install of the v0.23.0 dev (second one), and it works wonderfully

Thank you MOAR for all the hard work and allowing us to enjoy the mod :)

I'm glad it works, and thank you for checking it. It looks like I'll get v0.23.0 wrapped up in a few days here, and I'll make an official release of it.

Link to comment
Share on other sites
MOARdV

MOARdV

Posted
  • Author
Posted

Latest update to the dev build went live on DropBox. Notable features:

  • Resized a couple of DDS texture to (hopefully) eliminate the "black HUD ladder" bug and another one.
  • Added new MechJeb space plane interface and data queries.
  • New variables to view lift and drag on the craft (for stock aero - don't expect it to work with FAR).
  • Ability to query Kerbal Alarm Clock for the number of alarms that apply to the current vessel, as well as some info on the next alarm for the vessel.
  • New PartModule JSIRadar that can automatically target vessels. There are several knobs you can turn in the config to tune the behavior, and this one does not require IVA to work.

Look at the release notes and the wiki for more details.

Link to comment
Share on other sites
Xgkkp

Xgkkp

Posted
Posted

I'm a little confused by the PITCHPROGRADE, PITCHRETROGRADE and family variables. I'd expect they would give me the information required to draw a navball, but they don't seem to. Example: Asking for PITCH/YAW PROGRADE/RETROGRADE I get:


Position for Prograde:    (pitch:  0.860445 , yaw:  62.2183 )
Position for Retrograde:  (pitch: -0.860445 , yaw: -62.2183 )

Which is the absolute position to draw them, but gives me no information about which one we are actually facing. Is this by design? Am I just misusing these variables?

Link to comment
Share on other sites
MOARdV

MOARdV

Posted
  • Author
Posted
Which is the absolute position to draw them, but gives me no information about which one we are actually facing. Is this by design? Am I just misusing these variables?

They're not replacements for a NavBall. What they do is provide the angle (in the pitch and yaw axes) between the front of the craft and the direction being tracked. But, yeah, it is unclear which of those variables you're facing (one of the yaw values should be > 90 to indicate it's behind you). go revisit the algorithm and see why that information is being lost.

Link to comment
Share on other sites
MOARdV

MOARdV

Posted
  • Author
Posted
They're not replacements for a NavBall. What they do is provide the angle (in the pitch and yaw axes) between the front of the craft and the direction being tracked. But, yeah, it is unclear which of those variables you're facing (one of the yaw values should be > 90 to indicate it's behind you). go revisit the algorithm and see why that information is being lost.

Let me correct that last sentence: I'll go revisit the algorithm ... and, yeah, it was a bit odd, since it only provides values in the range +/- 90. I've fixed that, and the next dev build will include the fix (hopefully late today, since I'll be out on business for a few days).

@MOARdv: I am about to create an IVA and I understand that you can have transparent windows with RPM. How would I go about doing that? Is that feature in the documentation somewhere? Thanks! :)

Outside of the stuff on GitHub, I don't have anything else to provide. It's not code I'm very familiar with, so I don't know if there's anything missing from that documentation.

Link to comment
Share on other sites
Angelo Kerman

Angelo Kerman

Posted
Posted
Let me correct that last sentence: I'll go revisit the algorithm ... and, yeah, it was a bit odd, since it only provides values in the range +/- 90. I've fixed that, and the next dev build will include the fix (hopefully late today, since I'll be out on business for a few days).

Outside of the stuff on GitHub, I don't have anything else to provide. It's not code I'm very familiar with, so I don't know if there's anything missing from that documentation.

Much appreciated, thank you :)

Link to comment
Share on other sites
JPLRepo

JPLRepo

Posted
Posted
Much appreciated, thank you :)

I've just finished making two parts using RPM transparency and submitted two updates that MOARdV has applied to the transparent pod code.

It works great. The GitHub instructions are correct and complete. If you have questions PM me.

cheers.

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