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

[Jebs_SY]

Hello @MOARdV

if I see that all correctly, in that screenshot both MFDs are the "ALCORMFD60x30" and they have "screenPixelWidth = 960" and "screenPixelHeight = 1024".
The interesting thing is, that the "map" is OK, but only the "ore overlay" seems not scaled properly.
Here I wonder, if "map" and "ore overlay" are two different images/information, that RPM gets from scansat and RPM combines them, or if RPM just requests a "map with ore overlay" and scansat combines them and delivers it as one image/information.

No need for a sorry, it's not a deal breaker. Much thanks for all your work with RPM. It's great. I really love it.
It just has a litte performance impact on my highly modded install, but that's the way it is. BTW, are there hints where one can lower the performance impact a little? Maybe change the refresh rate or such things?

BR
Jebs

Edited October 3, 2017 by Jebs_SY

[MOARdV]

RPM is not involved with the overlay at all.  The way SCANsat's RPM interface works (and the way Vessel Viewer and DPAI work, as well), is that there is an interface DLL included in the mod.  That interface DLL provides an entry point for RPM to call, as specified in the MFD's config file (in the SCANsat case, method = MapRenderer).  RPM says, "Hey, draw whatever you're going to draw on this", and it displays those contents with no additional processing (other than possibly drawing text over it).

Without looking at what SCANsat's RPM DLL is doing, it's hard to say why the ore overlay is messed up.  It's possible, since the MFD's dimensions are both non-square, and non-640x640, that there are some assumptions in the DLL that are incorrect, but that's speculation on my part.

You can change the refresh rate of the MFD by changing refreshDrawRate, refreshTextRate, and refreshDataRate in the MFD's config, but that will make the MFD update slower than it already does (less frequent updates, so data will become stale quicker).

[Jebs_SY]

Hello @MOARdV

OK, thank you very much. Wouldn't that mean, that when the overlay is correct on Page1 on MFD-Type-A, but incorrect streched on Page2 on MFD-Type-A (same MFD Type) that is then only can be a scansat-rpm-DLL issue?
I mean it's correct on one page, but incorrect on another page on the same MFD type.

BR
Jebs

[MOARdV]

6 hours ago, Jebs_SY said:

Hello @MOARdV

OK, thank you very much. Wouldn't that mean, that when the overlay is correct on Page1 on MFD-Type-A, but incorrect streched on Page2 on MFD-Type-A (same MFD Type) that is then only can be a scansat-rpm-DLL issue?
I mean it's correct on one page, but incorrect on another page on the same MFD type.

BR
Jebs

I took a look at the configs for the two scansat pages in that prop.  One page uses startLine/stopLine, but the other does not.  There are also different zoomModifiers.  The issue is either that there's a problem with the specific settings in one of these pages (possible), or that the DLL is not correctly handling some of those values.  Since resource overlays are a newer feature in SCANsat (compared to the RPM DLL), I would suspect that's where the issue is.

[DMagic]

@MOARdV @Jebs_SY I think the issue is that the ALCOR MFD's in question just haven't been added to SCANsat's list of MM patches. These non-standard screens require some changes to make sure the map is only drawn on the correct part of the screen. I'm updating SCANsat soon, so I can just add in or fix patches for any extra ALCOR MFD's.

[MOARdV]

3 hours ago, DMagic said:

@MOARdV @Jebs_SY I think the issue is that the ALCOR MFD's in question just haven't been added to SCANsat's list of MM patches. These non-standard screens require some changes to make sure the map is only drawn on the correct part of the screen. I'm updating SCANsat soon, so I can just add in or fix patches for any extra ALCOR MFD's.

@alexustas is actively working on the props in question, so if it's a case of fixing the config file, it may be worthwhile to contact him and provide the changes needed, so that they're updated to the current SCANsat requirements.

[Jebs_SY]

@DMagic @MOARdV @alexustas

It's not a game breaker, so if it's to hard to find, we maybe should let it be.
But because I started it, I still wanna give the latest information I found.

-It's not related to ALCOR only. It happens with the ASET props. They are used by (f.e. the MK1-2 pod IVA and also by ALCOR).
-Removing "SCANsat\MM_Parts\MFDPatches.cfg" doesn't change anything (I thing because ASET already uses these value).
-If someone want's to debug it, one needs 1.3.0-Vanilla + Scansat18 + MK1-2IVAReplacement0.2 + RPM0.29 (and I suggest USI MKS for more resource layers to compare)

I made one more screenshot set, where you can see the problem. However, just if anyone is interested. I can live with it, so this is not a fix request.  o/

 

BR
Jebs

[/dev/urandom]

Some Mk1 Cockpit elements are positioned wrong after installing mod.

 

1. Verified Steam cache (build 1.3.1.1891, x64).

2. Cleaned GameData folder (except "Squad" subfolder).

3. Installed RasterPropMonitor0.29.0, ModuleManager-2.8.1.

4. Restarted scenario "Refuel at Minmus".

5. Switched view to in-cockpit ("C" key).

6. Looked left.

 

Result:

Spoiler

Hatch doors are rotated:

 

Unexpected texture is shown.

 

Display is rotated too:

Edited October 7, 2017 by /dev/urandom
After deleting album on image hosting attachments disappeared from post, reuploaded it

[linuxgurugamer]

Does anybody know if this works in 1.3.1?  OP still says 1.3.0

Thanks

[MOARdV]

42 minutes ago, linuxgurugamer said:

Does anybody know if this works in 1.3.1?  OP still says 1.3.0

Thanks

RPM v0.29.0 appears to work in 1.3.1, but it turns out I had a couple of commits sitting on my local drive, so I've released v0.29.1.  The only changes are a possible NRE fix in the VAB when certain mods are used, and support for filtering Relay vessels in the MFD target menu.

[linuxgurugamer]

38 minutes ago, MOARdV said:

RPM v0.29.0 appears to work in 1.3.1, but it turns out I had a couple of commits sitting on my local drive, so I've released v0.29.1.  The only changes are a possible NRE fix in the VAB when certain mods are used, and support for filtering Relay vessels in the MFD target menu.

The .version file is somewhat wrong, it says both KSP version of 1.3.1, and then a KSP_verion_min of 1.3.0, it also has a trailing comma which fails JSON checks.

I've seen some odd behaviour from both CKAN (I know you don't support it) and AVC when there is both a KSP_VERSION and a KSP_VERSION_MIN

Can I suggest the following as a fix:

{
  "NAME": "RasterPropMonitor",
  "URL": "https://raw.githubusercontent.com/Mihara/RasterPropMonitor/master/GameData/JSI/RasterPropMonitor/RasterPropMonitor.version",
  "DOWNLOAD": "https://github.com/Mihara/RasterPropMonitor/releases",
  "VERSION": {
    "MAJOR": 0,
    "MINOR": 29,
    "PATCH": 1
  },
  "KSP_VERSION_MIN": {
    "MAJOR": 1,
    "MINOR": 3,
    "PATCH": 0
  },
  "KSP_VERSION_MAX": {
    "MAJOR": 1,
    "MINOR": 3,
    "PATCH": 1
  }
}

 

[MOARdV]

1 hour ago, linuxgurugamer said:

The .version file is somewhat wrong, it says both KSP version of 1.3.1, and then a KSP_verion_min of 1.3.0, it also has a trailing comma which fails JSON checks.

I've seen some odd behaviour from both CKAN (I know you don't support it) and AVC when there is both a KSP_VERSION and a KSP_VERSION_MIN

 

Sure, I can update it.  I wasn't aware that AVC didn't like that construct.

[maja]

@linuxgurugamer @MOARdV From online KSP AVC Readme ( http://ksp.cybutek.net/kspavc/Documents/README.htm ):

KSP_VERSION - Optional, Required for MIN/MAX
Version of KSP that the add-on was made to support.

KSP_VERSION_MIN - Optional
Minimum version of KSP that the add-on supports.
Requires KSP_VERSION field to work.

KSP_VERSION_MAX - Optional
Maximum version of KSP that the add-on supports.
Requires KSP_VERSION field to work.

[linuxgurugamer]

Just now, maja said:

@linuxgurugamer @MOARdV From online KSP AVC Readme ( http://ksp.cybutek.net/kspavc/Documents/README.htm ):

KSP_VERSION - Optional, Required for MIN/MAX
Version of KSP that the add-on was made to support.

KSP_VERSION_MIN - Optional
Minimum version of KSP that the add-on supports.
Requires KSP_VERSION field to work.

KSP_VERSION_MAX - Optional
Maximum version of KSP that the add-on supports.
Requires KSP_VERSION field to work.

I know what it says, but I've seen cases where, when KSP_VERSION is specified, the MIN and MAX are ignored.  I suppose it's possible that if the KSP_VERSION doesn't equal one of the other two, that it gets ignored.

I'll have to take a dive into the code later

[MOARdV]

56 minutes ago, maja said:

@linuxgurugamer @MOARdV From online KSP AVC Readme ( http://ksp.cybutek.net/kspavc/Documents/README.htm ):

KSP_VERSION - Optional, Required for MIN/MAX
Version of KSP that the add-on was made to support.

KSP_VERSION_MIN - Optional
Minimum version of KSP that the add-on supports.
Requires KSP_VERSION field to work.

KSP_VERSION_MAX - Optional
Maximum version of KSP that the add-on supports.
Requires KSP_VERSION field to work.

That's most likely where I got the format I used.  It's been a few years since I added those fields.  @linuxgurugamer, please let me know what you find in the AVC code.  I've already pushed your recommended change to GitHub, so if that's going to cause grief with AVC, I'd like to revert it (other than the spurious comma that was in there).

[linuxgurugamer]

Just now, MOARdV said:

That's most likely where I got the format I used.  It's been a few years since I added those fields.  @linuxgurugamer, please let me know what you find in the AVC code.  I've already pushed your recommended change to GitHub, so if that's going to cause grief with AVC, I'd like to revert it (other than the spurious comma that was in there).

It shouldn't, but I'll look at it now.

Thanks 

[linuxgurugamer]

14 minutes ago, MOARdV said:

That's most likely where I got the format I used.  It's been a few years since I added those fields.  @linuxgurugamer, please let me know what you find in the AVC code.  I've already pushed your recommended change to GitHub, so if that's going to cause grief with AVC, I'd like to revert it (other than the spurious comma that was in there).

Ok, from what I see in the code, KSP_VERSION is not required for the min or max to work. It's optional from what I can tell, essentially you need at least one of them set.

Here is the important code, it's duplicated in both the full AVC and  Mini-AVC:

public bool IsCompatible
{
	get { return IsCompatibleKspVersion || ((kspVersionMin != null || kspVersionMax != null) && IsCompatibleKspVersionMin && IsCompatibleKspVersionMax); }
}

public bool IsCompatibleKspVersion
{
	get { return Equals(KspVersion, actualKspVersion); }
}

public bool IsCompatibleKspVersionMax
{
	get { return KspVersionMax >= actualKspVersion; }
}

public bool IsCompatibleKspVersionMin
{
	get { return KspVersionMin <= actualKspVersion; }
}

 

I found the following:

 public bool IsUpdateAvailable
        {
            get { return this.IsProcessingComplete && 
                    this.LocalInfo.Version != null && 
                    this.RemoteInfo.Version != null && 
                    this.RemoteInfo.Version > this.LocalInfo.Version && 
                    this.RemoteInfo.IsCompatibleKspVersion && 
                    this.RemoteInfo.IsCompatibleGitHubVersion; }
        }

which seems to indicate that the KSP_VERSION actually IS necessary.  But I'm wondering if this is a bug.

I'd say for now, put it back, but I'm going to contact @cybutek about it

Edited October 9, 2017 by linuxgurugamer

[snakeru]

Hi. I have a question about RPM MFDs and their function without the energy. In my ship designs it sometimes happens that energy is being consumed all the time and then, eventually, runs out.
MFDs at this point freeze and stop updating.

That would have been OK, if not that other thing - my kerbal pilots often have 100% stupidity. They keep staring dumbly at non-updating monitors and keep playing with time speed up/down buttons to figure out what went wrong. And when they finally decide to take a look out of the window - it's already too late to make this "High over the Mun" report and time to write down the "Low over the Mun" one. Or better yet, stage and transition directly into landing sequence.

What setting should I tweak to make monitors go OFF when there is no more energy?

Edited October 10, 2017 by snakeru

[MOARdV]

5 hours ago, snakeru said:

Hi. I have a question about RPM MFDs and their function without the energy. In my ship designs it sometimes happens that energy is being consumed all the time and then, eventually, runs out.
MFDs at this point freeze and stop updating.

That would have been OK, if not that other thing - my kerbal pilots often have 100% stupidity. They keep staring dumbly at non-updating monitors and keep playing with time speed up/down buttons to figure out what went wrong. And when they finally decide to take a look out of the window - it's already too late to make this "High over the Mun" report and time to write down the "Low over the Mun" one. Or better yet, stage and transition directly into landing sequence.

What setting should I tweak to make monitors go OFF when there is no more energy?

IT looks like that is a bug.  The monitors by default are supposed to go blank when power is out, but there's some code that currently bypasses the blanking and simply causes it to freeze, instead.

[linuxgurugamer]

20 hours ago, linuxgurugamer said:

Ok, from what I see in the code, KSP_VERSION is not required for the min or max to work. It's optional from what I can tell, essentially you need at least one of them set.

Here is the important code, it's duplicated in both the full AVC and  Mini-AVC:

public bool IsCompatible
{
	get { return IsCompatibleKspVersion || ((kspVersionMin != null || kspVersionMax != null) && IsCompatibleKspVersionMin && IsCompatibleKspVersionMax); }
}

public bool IsCompatibleKspVersion
{
	get { return Equals(KspVersion, actualKspVersion); }
}

public bool IsCompatibleKspVersionMax
{
	get { return KspVersionMax >= actualKspVersion; }
}

public bool IsCompatibleKspVersionMin
{
	get { return KspVersionMin <= actualKspVersion; }
}

 

I found the following:

 public bool IsUpdateAvailable
        {
            get { return this.IsProcessingComplete && 
                    this.LocalInfo.Version != null && 
                    this.RemoteInfo.Version != null && 
                    this.RemoteInfo.Version > this.LocalInfo.Version && 
                    this.RemoteInfo.IsCompatibleKspVersion && 
                    this.RemoteInfo.IsCompatibleGitHubVersion; }
        }

which seems to indicate that the KSP_VERSION actually IS necessary.  But I'm wondering if this is a bug.

I'd say for now, put it back, but I'm going to contact @cybutek about it

I've definitely confirmed that there is a bug in AVC. I've posted on the thread and sent a PR to @cybutek to fix it.

I hope he fixes it soon.

[Ser]

Hello, people.

Is there a way to edit custom variables with MM patch?

Here's what I mean:

As I see, any RPM variable definition is just a plain config. So it looks like it could be edited with MM patch.

I have a part and I want the ASET props to properly display its EC output. The best way is to add it to a certain ASET custom variable. I've tried the following approach:

RPMCVARIABLEHANDLER //Define my own variable that is supplied by a PartModule
{
    name = MyRPMVariableHandler
    method = processRPMVariable
    variable = MY_HANDLER_VARIABLE,0,false
}

@RPM_CUSTOM_VARIABLE[ALCOR_FUELCELL_OUTPUT] //Rename the existing variable
{
   @name = ALCOR_FUELCELL_OUTPUT_RENAMED
}

RPM_MATH_VARIABLE //Replace the old variable with my value added
{
	name = ALCOR_FUELCELL_OUTPUT
	operator = ADD
	sourceVariable = CUSTOM_ALCOR_FUELCELL_OUTPUT_RENAMED
	sourceVariable = MY_HANDLER_VARIABLE
}

Thus the props wouldn't notice anything and would keep displaying the same variable but with my value added. Also it would be compatible with whatever does the same thing.

But that doesn't work. The handler isn't even asked for MY_HANDLER_VARIABLE.

So should that work or the only way is to declare a new variable and force the props to use it instead?

 

And another question: are operations on self allowed? I mean doing something like x = x + my:

//Assume that ALCOR_FUELCELL_OUTPUT is already defined by another mod

RPM_MATH_VARIABLE
{
	name = ALCOR_FUELCELL_OUTPUT
	operator = ADD
	sourceVariable = CUSTOM_ALCOR_FUELCELL_OUTPUT
	sourceVariable = MY_HANDLER_VARIABLE
}

 

Edited October 11, 2017 by Ser

[MOARdV]

5 hours ago, Ser said:

Is there a way to edit custom variables with MM patch?

I assume that renaming the custom variable would work.  An easier way to accomplish that may be to use MM to simply add 'sourceVariable = MY_HANDLER_VARIABLE' to the existing custom variable.  That would be less costly to evaluate than adding an extra custom variable.

 

5 hours ago, Ser said:

I have a part and I want the ASET props to properly display its EC output.

Keep in mind that the part module in question will be instantiated on the pod that RPM is on, if it wasn't installed previously.  RPM can't query a part module installed elsewhere.  Based on your config, you have a PartModule named `MyRPMVariableHandler` that has a public method `object processRPMVariable(string)`.  Provided that's correct, there may be messages from RPM indicating that it was unable to create or locate that module.  I'd recommend turning on the RPM debug logging in JSI/RasterPropMonitor/Plugins/PluginData/rpm-config.cfg, loading a craft with your part module and an RPM IVA, and searching through the log for messages containing 'ExternalVariableHandlers' or 'VariableHandler'.

One thing to keep in mind with the 'false' parameter - telling RPM that it can not be cached means that *every* time RPM needs to evaluate that variable during FixedUpdate, or potentially any custom variable that uses that variable, it will have to call your method.  That parameter is intended for use with random numbers, where you don't want the same result every time it's used in a single FixedUpdate.  For a typical variable that changes every FixedUpdate (altitude, heading, speed, EC production / consumption, etc.), you don't need to use the 'false' parameter.

 

6 hours ago, Ser said:

are operations on self allowed?

If it's cacheable data, that may work, but I wouldn't recommend it, since it depends on timing of the evaluations.  It could also trigger an infinite recursion and crash.

[Ser]

1 hour ago, MOARdV said:

An easier way to accomplish that may be to use MM to simply add 'sourceVariable = MY_HANDLER_VARIABLE' to the existing custom variable.  That would be less costly to evaluate than adding an extra custom variable.

It would be but the variable I'm trying to modify is declared with MULTIPLY, and if I understand right different operators cannot be used within the same declaration.

1 hour ago, MOARdV said:

Keep in mind that the part module in question will be instantiated on the pod that RPM is on, if it wasn't installed previously.  RPM can't query a part module installed elsewhere.

I've attached that module to an engine in config but found that it doesn't belong to it in runtime. So is there the need to attach this PartModule to any part in order to have it instantiated or does RPM do it automagically just from an existing type?

1 hour ago, MOARdV said:

Based on your config, you have a PartModule named `MyRPMVariableHandler` that has a public method `object processRPMVariable(string)`.  Provided that's correct, there may be messages from RPM indicating that it was unable to create or locate that module. 

Yes, that's right. Actually I have another variable that's used in a more straightforward way and I can see it evaluated, so the handler module is located by RPM. May be the problem is in evaluation chain, I could have messed up MATH and CUSTOM declarations. Thanks for the tip about logging, hope that'll make debugging less a hell.

Edited October 11, 2017 by Ser

[MOARdV]

1 hour ago, Ser said:

It would be but the variable I'm trying to modify is declared with MULTIPLY, and if I understand right different operators cannot be used within the same declaration.

Ah, okay.  In that case, yeah, you'll need to create the extra variable.  One of these days, I'll get MAS tidied up for a general release - it'll make things like this drastically easier.

 

1 hour ago, Ser said:

I've attached that module to an engine in config but found that it doesn't belong to it in runtime

RPM will only look for the RPM variable handler PartModule on the command pod that RPM is running on.  If it does not find the module, it will attempt to create it, but it still is going to be on the command pod.  If you need to access values generated by a module on a different part, then the 'MyRPMVariableHandler' will need to create those connections itself.  That is, when it starts, it will need to scan through the craft, look for engines that have your part module, and keep references to those modules so that it can produce values when RPM asks for them.

[Ser]

@MOARdV, The MM patches work, it was me having messed up CUSTOM and MATH prefixes and looking at the wrong variable.

Are you sure the variable ELECOUTPUTALTERNATOR is calculated properly? I specified the rate of EC resource output for alternator as 2. My engine's part menu shows that current output rate is 1.88 EC/s. I'm sure that inside alternator logic it is calculated as outputResource.rate * some thrust coefficient.

But EC gauge that uses ELECOUTPUTALTERNATOR shows something around 3.8. In the RPM's source code I see that alternatorOutput is calculated as:

alternatorOutput += availableAlternatorOutput[i] * availableAlternators[i].outputRate;

Where availableAlternatorOutput is the base resource rate from config. So it seems like that extra multiplication is not needed because it leads to the improper result: 2 * 1.88 = 3.76.

Edited October 12, 2017 by Ser