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

[MOARdV]

5 hours ago, RW-1 said:

1.3.1, latest mechjeb (MechJeb2-2.6.1.0-768) and RPM (RasterPropMonitor.0.29.2) integration.

It looks like you're using a dev build of MechJeb.  RPM does not support dev builds of MJ, because I don't have the time to maintain compatibility with the official released MJ version as well as a dev build which may change without notice.  You'll need to revert back to an older version of MJ, or do without RPM / MJ integration until MJ makes another stable release.

[RW-1]

MOAR,

 

Oh thank god!

 

I'll try reverting, I though I got myself into an irreversable mess, with all that I've installed lately 

 

I can live on a stable release of MJ, that's no issue ...

 

will report back.

 

UPDATE: You're my hero! 

Ahh, I'm glad I didnt have to go back to the beginning and start over to determine if some other install borked it.

It'sa back on my mark 1-2 with aset 3.0 IVA, so I suspect it whould be good across the board ...

 

Thanks, this had been bugging me for a few days now ...  and great work by the way!

Edited December 10, 2017 by RW-1

[RW-1]

MOAR,

 

Another question, I asked on SSTU ...

 

Using SSTU capsules and RPM, ASET props, the docking view camera seems to be showing the back of the docking port no matter what I do.

Shadow image seemed to think it is the model  or config, thus:

"Likely the RPM camera position/config is configured incorrectly.  Could be either in the models, or in the config.  Generally the SSTU parts with built-in docking ports -should- have viable docking camera transforms.  But I don't use RPM, so they have never been tested. (nor do I have any way to know if they were 'fixed' if I were to adjust them).

Sadly, not sure what to tell you on this one.  Short of someone taking a look at the models who also knows about RPM, it is not something that I'll be working on.  If someone can tell me exactly what needs to be done (e.g. move 'transform XXXX up 0.15m on X axis), I can likely get it fixed up, but I do not have the time or patience to find/download/setup RPM just to test a feature that I will never use and have no interest in."

 

I'm willing to test if the transforms can be adjusted, which is not something I believe I can try.

 

Thanks.

 

[MOARdV]

 

5 hours ago, RW-1 said:

Using SSTU capsules and RPM, ASET props, the docking view camera seems to be showing the back of the docking port no matter what I do

The docking camera in RPM is a special-case camera. 

In a conventional RPM camera, you provide a transform, and (optionally) rotation and translation components to configure it how you need.

For the docking camera, RPM searches the part for a transform named 'dockingNode'.  If it finds that transform, it uses it for the camera location.  If there isn't a transform with that name, RPM simply grabs the root transform (I believe) of the part.  There aren't any knobs you can adjust to move the docking camera around, either, so it'd require model changes to support RPM docking cameras.

You *could* add a conventional RPM camera to the part and adjust it to where you need it, but it would not work for a docking camera without also editing the MFD config.

FWIW, this will not be a problem in MAS, since every camera has to be specified.  I'm hoping to have a major update for MAS in the next week or two, although there's only one IVA currently available for it (and it's not an SSTU capsule).

[RW-1]

33 minutes ago, MOARdV said:

 

The docking camera in RPM is a special-case camera. 

In a conventional RPM camera, you provide a transform, and (optionally) rotation and translation components to configure it how you need.

For the docking camera, RPM searches the part for a transform named 'dockingNode'.  If it finds that transform, it uses it for the camera location.  If there isn't a transform with that name, RPM simply grabs the root transform (I believe) of the part.  There aren't any knobs you can adjust to move the docking camera around, either, so it'd require model changes to support RPM docking cameras.

You *could* add a conventional RPM camera to the part and adjust it to where you need it, but it would not work for a docking camera without also editing the MFD config.

FWIW, this will not be a problem in MAS, since every camera has to be specified.  I'm hoping to have a major update for MAS in the next week or two, although there's only one IVA currently available for it (and it's not an SSTU capsule).

MOAR,

 

I appreciate the time you took to reply / explain.

 

I'l pass onto Shadow Image, and also look at it, no biggie, may even try MAS once completed/updated! 

 

Have a great holiday!

Edited December 12, 2017 by RW-1

[ave369]

I, too, have an issue of no RPM monitors in the MK2 inline cockpit. The version is 1.3.1 and I have no mods that modify the MK2 inline cockpit.

Edited December 21, 2017 by ave369

[MOARdV]

47 minutes ago, ave369 said:

I, too, have an issue of no RPM monitors in the MK2 inline cockpit. The version is 1.3.1 and I have no mods that modify the MK2 inline cockpit.

During one of the revisions of space planes Squad made during the last couple of years, Squad changed the IVA for the Mk2 inline, and no one has submitted a basic replacement to use with RPM based on the updated IVA.

[ave369]

3 hours ago, MOARdV said:

During one of the revisions of space planes Squad made during the last couple of years, Squad changed the IVA for the Mk2 inline, and no one has submitted a basic replacement to use with RPM based on the updated IVA.

Can I do a dirty hack and replace the IVA for the inline cockpit with the IVA for the normal cockpit?

[Stone Blue]

@MOARdV getting this error, and a mod using this in an IVA seems to be broken.
[ERROR] [InternalProp.AddModule] Cannot find an InternalModule of typename 'RasterPropMonitorComputer'

just wondering if the module was deprecated at some point?... I just went thru the changelog for the past several versions, and didnt see anything mentioned about it...

Just wondering where I need to start troubleshooting

[MOARdV]

5 hours ago, Stone Blue said:

@MOARdV getting this error, and a mod using this in an IVA seems to be broken.
[ERROR] [InternalProp.AddModule] Cannot find an InternalModule of typename 'RasterPropMonitorComputer'

just wondering if the module was deprecated at some point?... I just went thru the changelog for the past several versions, and didnt see anything mentioned about it...

Just wondering where I need to start troubleshooting

No, that's the brains of RPM , not a deprecated module.  Without that module, the mod doesn't do anything.

Without additional info (logs), my guess is that the pod/part that you're using is missing the MODULE node that adds RasterPropMonitorComputer, which is odd.  RPM usually will try to create the Computer module on its own if it's not already present.  Sorry, that's about all I can come up with without additional info.

[Stone Blue]

1 hour ago, MOARdV said:

 Sorry, that's about all I can come up with without additional info.

Thats kewl... Thanx... i "thought" that that MODULE was pretty darn important...
you've given me a place to start digging... I wasnt expecting you to spend time looking into the issue yet... i have digging to do myself first, before I  "present my case" as a an even credible issue/support request.
And if that module is absolutely supposed to be there, then it is most likely not even an issue with RPM itself... The mod in question has plugins of its own, so its probably NOT just a case of a straight IVA not playing well with RPM...
Anyway, as always, thanx for taking the time for the response.

[AccidentsHappen]

Hey @MOARdV, I was wondering if there is any way to implement the BDArmory radar screens, bombing cams, etc to RPM screens inside cockpits. If not, could you give me some sort of pointer of it would be possible or not?

Many thanks in advance

[MOARdV]

9 hours ago, AccidentsHappen said:

Hey @MOARdV, I was wondering if there is any way to implement the BDArmory radar screens, bombing cams, etc to RPM screens inside cockpits. If not, could you give me some sort of pointer of it would be possible or not?

Many thanks in advance

It is possible to do so, but I won't be the one doing it .  I don't use BDArmory, and I'm not developing new features for RPM in general (since I am working on MAS instead). The easiest way would be to make a class in BD Armory that provided button handling and MFD screen rendering similar to the JSISCANsatRPM class in SCANsat.  There's some documentation on the RPM wiki, but I think it is fairly straightforward.   An up-side to this approach is that it would be something MAS could use, as well.

There would also need to be MM patches that tweak the MFDs to allow the new pages to be accessed, of course.

[MOARdV]

I had a little bit of time to look at the problem with RasterPropMonitor and MechJeb dev builds.  There's an updated RPM build available now, v0.29.3, on GitHub.  It also includes a feature from Ser to allow parts to opt out of RPM's data tracking, as well, for mods that need that capability.

Note that the MechJeb changes nerf most of RPM's space plane MechJeb interface (although I don't know how many IVAs actually used those features, so it may not actually affect anyone).

[theonegalen]

What do you mean they nerf the spaceplane interior? The smartA.S.S. buttons? I thought there were several cockpits that used those, and I know I was working on a couple.

[MOARdV]

8 hours ago, theonegalen said:

What do you mean they nerf the spaceplane interior? The smartA.S.S. buttons? I thought there were several cockpits that used those, and I know I was working on a couple.

No, they nerf the MechJeb spaceplane guidance interface features - specifically, RPM could toggle MJ's hold heading / altitude autopilot, and configure that autopilot.  That functionality will not work with newer versions of MechJeb dev builds.  Any props using the disabled functionality will be decorative.

[theonegalen]

i didn't even realise MJ had a heading / altitude hold. I was using Pilot Assistant for that functionality in all the cockpits I was working on.

[JPNB]

Hi, I'm having a little bug. On orbital and map view the vessel icon and target vessel icon disappeared and I can't find a way to fix it. It worked and then suddenly was gone. I tried reinstalling RPM and Alcor but no result.. Can someone please help me. Thank you.

 

Edit: It doesn't show any icons actually. Ascend and Descent etc aren't displayed as well.

Edited January 22, 2018 by JPNB

[theonegalen]

Hey @MOARdV, I'm trying to make a prop that will output how long the engines can burn before they run out of fuel. Right now I'm attempting to use a Math variable as such:

RPM_MATH_VARIABLE
{
   name = WARBIRD_FLIGHTTIME
   operator = DIVIDE

   sourceVariable = SYSR_LIQUIDFUEL
   sourceVariable = SYSR_LIQUIDFUELDELTA
}

But all I'm getting is an NRE error and the log tells me that my variable "MATH_WARBIRD_FLIGHTTIME" referenced in the prop doesn't exist. Is it because SYSR_LIQUIDFUELDELTA is 0 when the ship is loaded, resulting in a DIV/0 error? I also tried to put it in a select variable that set the output to 0 whenever SYSR_LIQUIDFUELDELTA was 0, but it then said my select variable didn't exist either. Do you think there's any better way to get to the desired result?

Edited January 24, 2018 by theonegalen

[MOARdV]

1 hour ago, theonegalen said:

Do you think there's any better way to get to the desired result?

Flippantly, I'd say "Switch to MAS".  Time remaining computations are easy to do, and MAS provides safeguards for divide-by-zero.  The biggest downside is most of alexustas's props still need converted to MAS (especially the mechanical aviation props).

For an RPM-centric answer ... Can you make sure DebugLogging is set to true in JSI/RasterPropMonitor/Plugins/PluginData/rpm-config.cfg, and provide a log?  I would expect a divide-by-zero error to generate a NaN or INF result, not an NRE.  And I'd not expect an error about the variable not existing.  It sounds like maybe there's something else going on that's causing the variable to misbehave, since I don't see anything obviously incorrect in what you've posted.

[theonegalen]

Just now, MOARdV said:

Flippantly, I'd say "Switch to MAS".  Time remaining computations are easy to do, and MAS provides safeguards for divide-by-zero.  The biggest downside is most of alexustas's props still need converted to MAS (especially the mechanical aviation props).

For an RPM-centric answer ... Can you make sure DebugLogging is set to true in JSI/RasterPropMonitor/Plugins/PluginData/rpm-config.cfg, and provide a log?  I would expect a divide-by-zero error to generate a NaN or INF result, not an NRE.  And I'd not expect an error about the variable not existing.  It sounds like maybe there's something else going on that's causing the variable to misbehave, since I don't see anything obviously incorrect in what you've posted.

Trust me, as soon as I have time to recode all the props I've customized, I'm switching right over to MAS. Right now, with a full course load at uni, 30-40 hours of work a week, and other commitments, I just don't have time to learn how MAS works and adapt everything over.

I'll see if I can get a log out of it tonight. I'll also quadruple-check my customs config to see if I left a dangling bracket somewhere. 

[theonegalen]

@MOARdV, I'm sorry it's taking me so long to get the log, I've been working, in class, or sleeping every hour the past few days.

I actually have a nother question, though. Do the IASPEED and EASPEED variables depend on information from stock aerodynamics (temperature, pressure, etc)? Because my Indicated Airspeed gauge doesn't seem to work when I'm using FAR.

[MOARdV]

10 hours ago, theonegalen said:

@MOARdV, I'm sorry it's taking me so long to get the log, I've been working, in class, or sleeping every hour the past few days.

I actually have a nother question, though. Do the IASPEED and EASPEED variables depend on information from stock aerodynamics (temperature, pressure, etc)? Because my Indicated Airspeed gauge doesn't seem to work when I'm using FAR.

No worries on the log.  I remember those crazy-busy days from university.

It looks like the airspeed variables depend on dynamic pressure as reported on the part (each part on a vessel has a dynamic pressure field), and the stagnation pressure computation depends on a celestial body's atmosphere adiabatic index.  I recall that FAR stomps at least some of those values to keep stock aero from working, so it's entirely likely that those values are incompatible with FAR.

[theonegalen]

16 minutes ago, MOARdV said:

No worries on the log.  I remember those crazy-busy days from university.

It looks like the airspeed variables depend on dynamic pressure as reported on the part (each part on a vessel has a dynamic pressure field), and the stagnation pressure computation depends on a celestial body's atmosphere adiabatic index.  I recall that FAR stomps at least some of those values to keep stock aero from working, so it's entirely likely that those values are incompatible with FAR.

Aha! I thought that might be the case. How difficult would it be for MAS to automatically pull those numbers from FAR when installed? I'd like to avoid having to make separate cockpits for FAR users and stock aero users as much as possible.

[MOARdV]

47 minutes ago, theonegalen said:

Aha! I thought that might be the case. How difficult would it be for MAS to automatically pull those numbers from FAR when installed? I'd like to avoid having to make separate cockpits for FAR users and stock aero users as much as possible.

MAS already uses FAR (when installed) to report dynamic pressure.  It uses a different algorithm than RPM to compute EAS and IAS that doesn't seem to be affected by FAR (although I'm not positive the IAS computation is right).