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

[Prof.Xomox]

Thanks MOARdV! Made an account to thank you, long time player who has benefited from mods you and many others have made. Thanks to all of you that make it so I can play the game I want to play.

[Whovian41110]

Umm this happened.  So I walked up to my Mun base and it spontaneously helicoptered away.  Here's the log

https://www.dropbox.com/s/ttdnpsl6cdjwxsf/KSP.log?dl=0

I think it's this mod's fault because i got a JSI alert on screen

 

[ironhawx]

On 3/30/2016 at 4:06 PM, MOARdV said:

@JPLRepo - Thanks.  You phrased it more gently than I was about to do.

For an official statement: "KSP 1.1 has not released.  When it releases, I will work on updating RPM (and DoE).  I can not provide an estimate on how long it will take, because I don't know what it will take for me to update the mods, and I have been very busy with work this spring.  But I can guarantee that the more posts there asking me when it will be ready, the longer it will take me to finish it. "

So if ppl simply say thank you and take your time does it mean it would speed it up  Sry the smart ass in me couldn't resist, but seriously love the mod and wanted to share my appreciation to you and the other modders for what you all do.  Its because of your mod and a few others that i'm able to enjoy doing full iva missions and really missing that ability right now, one never realizes how much you enjoy or use something till its gone.  So can't wait for the update but by all means take your time  cheers mate

 

Edited April 3, 2016 by ironhawx

[MOARdV]

17 hours ago, Whovian41110 said:

Umm this happened.  So I walked up to my Mun base and it spontaneously helicoptered away.  Here's the log

https://www.dropbox.com/s/ttdnpsl6cdjwxsf/KSP.log?dl=0

I think it's this mod's fault because i got a JSI alert on screen

 

It's not this mod's fault.  You have a very heavily modded installation, and I see unhandled exceptions from ProceduralParts, ActiveTextureManagement, LifeSupportManager, KerbalAlarmClock, KerbalKonstructs, and MechJeb all before you get to the flight scene on the Mun.  The craft you loaded on the Mun is throwing a null reference exception in a docking node that spams the error log.

RPM determined something was messed up because your craft failed to registering properly with RPM when it loaded, and it put a message up on the screen instead of only putting it in the log.  Unfortunately, with all of the null refs in that log, I can't do a lot about it.

Have you added or removed mods or parts from that installation recently?

[Andem]

13 hours ago, ironhawx said:

So if ppl simply say thank you and take your time does it mean it would speed it up  Sry the smart ass in me couldn't resist, but seriously love the mod and wanted to share my appreciation to you and the other modders for what you all do.  Its because of your mod and a few others that i'm able to enjoy doing full iva missions and really missing that ability right now, one never realizes how much you enjoy or use something till its gone.  So can't wait for the update but by all means take your time  cheers mate

 

AFAIK Active Texture Management no longer functions, you could try Dynamic Texture loader tho. Like said above, RPM does nothing to the EVA part or kerbals in general.

[Whovian41110]

4 hours ago, MOARdV said:

It's not this mod's fault.  You have a very heavily modded installation, and I see unhandled exceptions from ProceduralParts, ActiveTextureManagement, LifeSupportManager, KerbalAlarmClock, KerbalKonstructs, and MechJeb all before you get to the flight scene on the Mun.  The craft you loaded on the Mun is throwing a null reference exception in a docking node that spams the error log.

RPM determined something was messed up because your craft failed to registering properly with RPM when it loaded, and it put a message up on the screen instead of only putting it in the log.  Unfortunately, with all of the null refs in that log, I can't do a lot about it.

Have you added or removed mods or parts from that installation recently?

Nope.  

[Fwiffo]

Does anyone else experience a KSP.exe crash if an externally mounted camera's FOV marker is left on for a while in the editor?  I have it crash after approx <= 10 minutes, even if it's just sitting there without me doing anything.  Fairly consistently recreatable with a couple of craft I have.

[MOARdV]

1 hour ago, Fwiffo said:

Does anyone else experience a KSP.exe crash if an externally mounted camera's FOV marker is left on for a while in the editor?  I have it crash after approx <= 10 minutes, even if it's just sitting there without me doing anything.  Fairly consistently recreatable with a couple of craft I have.

Can you please provide logs from one of the crash sessions?  This is the first I've heard of it.

[Fwiffo]

@MOARdV Sure, here's one: http://tinyurl.com/fovcrashlog1

Note there seems to be a lot more debug noise in this one than previous times I've seen.  Can try to grab a cleaner one for you if needed.

If it helps, it seems to occur not long after I see these lines:

[LOG 20:56:08.526] [SCANsat] start: in editor
[LOG 20:56:08.527] [SCANsat] sensorType: 0 fov: 0 min_alt: 0 max_alt: 0 best_alt: 0 power: 0.05

I do have several mods in my game and have not yet done further troubleshooting to isolate the cause.  I tried reproducing with a simple strut and camera, but it didn't occur (at least not yet).

Here's a craft file that recreates it (at least in my installation): http://tinyurl.com/fovcrashcraft

Open it in the editor, turn the Fov marker light on, pan the view around a bit, then let it sit for about 10 mins.  Far as I can tell the crash doesn't happen if the Fov marker is left off.

You'll need this part, too, to open that craft file: http://tinyurl.com/zencamera

You should also know the log is from KSP 64-bit.  (Like I said, haven't investigated much yet, just was putting a feeler out to see if anyone else had such an issue)

Edit: Here's another log, with the unmodded camera part http://tinyurl.com/FovCrashLog2

Edited April 4, 2016 by Fwiffo

[toril]

concerning your test release on ksp1183 64 bit with the cameras installed. You do not get a fov marker in the vab, and while in flight the camera loses track of the spacecraft until you manage to timewarp then it reacquires.

in the log i see a lot of these :

[EXC 21:13:00.031] NullReferenceException: Object reference not set to an instance of an object
    RenderingManager.AddToPostDrawQueue (Int32 queueSpot, .Callback drawFunction)
    JSI.JSIExternalCameraSelector.CreateLightCone ()
    JSI.JSIExternalCameraSelector.Update ()

and in the data log

NullReferenceException: Object reference not set to an instance of an object
  at RenderingManager.AddToPostDrawQueue (Int32 queueSpot, .Callback drawFunction) [0x00000] in <filename unknown>:0
  at JSI.JSIExternalCameraSelector.CreateLightCone () [0x00000] in <filename unknown>:0
  at JSI.JSIExternalCameraSelector.OnStart (StartState state) [0x00000] in <filename unknown>:0
  at Part.ModulesOnStart () [0x00000] in <filename unknown>:0
  at Part+<Start>c__Iterator25.MoveNext () [0x00000] in <filename unknown>:0 
 
(Filename:  Line: -1)

in the vab im assuming and these inflight: 

[EXC 22:05:27.839] TargetException: Non-static field requires a target
    System.Reflection.MonoField.GetValue (System.Object obj)
    JSI.JSIMechJeb.AutopilotEnabled ()
    JSI.MechJebRPM.GetActiveMode ()
    JSI.MechJebRPM.UpdateRootMenu ()
    JSI.MechJebRPM.ShowMenu (Int32 width, Int32 height)
    JSI.MonitorPage.get_Text ()
    JSI.RasterPropMonitor.FillScreenBuffer ()
    JSI.RasterPropMonitor.OnUpdate ()
    InternalProp.OnUpdate ()
    InternalModel.OnUpdate ()
    Part.InternalOnUpdate ()
    Part.Update ()

and the data log

TargetException: Non-static field requires a target
  at System.Reflection.MonoField.GetValue (System.Object obj) [0x00000] in <filename unknown>:0
  at JSI.JSIMechJeb.AutopilotEnabled () [0x00000] in <filename unknown>:0
  at JSI.MechJebRPM.GetActiveMode () [0x00000] in <filename unknown>:0
  at JSI.MechJebRPM.UpdateRootMenu () [0x00000] in <filename unknown>:0
  at JSI.MechJebRPM.ShowMenu (Int32 width, Int32 height) [0x00000] in <filename unknown>:0
  at JSI.MonitorPage.get_Text () [0x00000] in <filename unknown>:0
  at JSI.RasterPropMonitor.FillScreenBuffer () [0x00000] in <filename unknown>:0
  at JSI.RasterPropMonitor.OnUpdate () [0x00000] in <filename unknown>:0
  at InternalProp.OnUpdate () [0x00000] in <filename unknown>:0
  at InternalModel.OnUpdate () [0x00000] in <filename unknown>:0
  at Part.InternalOnUpdate () [0x00000] in <filename unknown>:0
  at Part.Update () [0x00000] in <filename unknown>:0 
 
(Filename:  Line: -1)

I also, can not get any of the cameras to show a picture on the screens. I have the full log+data log and ship used if you need it.

      Time of this report: 4/3/2016, 23:06:02
             Machine name: DESKTOP-DT9Q0CO
         Operating System: Windows 10 Pro 64-bit (10.0, Build 10586) (10586.th2_release_sec.160223-1728)
                 Language: English (Regional Setting: English)
      System Manufacturer: ASUS
             System Model: All Series
                     BIOS: 2702
                Processor: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz (8 CPUs), ~4.0GHz
                   Memory: 16384MB RAM
      Available OS Memory: 16258MB RAM
                Page File: 3820MB used, 14869MB available
              Windows Dir: C:\WINDOWS
          DirectX Version: 12
      DX Setup Parameters: Not found
         User DPI Setting: Using System DPI
       System DPI Setting: 96 DPI (100 percent)
          DWM DPI Scaling: Disabled
                 Miracast: Available, with HDCP
Microsoft Graphics Hybrid: Not Supported
           DxDiag Version: 10.00.10586.0000 64bit Unicode
 

[JPLRepo]

3 minutes ago, toril said:

concerning your test release on ksp1183 64 bit with the cameras installed. You do not get a fov marker in the vab, and while in flight the camera loses track of the spacecraft until you manage to timewarp then it reacquires.

in the log i see a lot of these :

[EXC 21:13:00.031] NullReferenceException: Object reference not set to an instance of an object
    RenderingManager.AddToPostDrawQueue (Int32 queueSpot, .Callback drawFunction)
    JSI.JSIExternalCameraSelector.CreateLightCone ()
    JSI.JSIExternalCameraSelector.Update ()

and in the data log

NullReferenceException: Object reference not set to an instance of an object
  at RenderingManager.AddToPostDrawQueue (Int32 queueSpot, .Callback drawFunction) [0x00000] in <filename unknown>:0
  at JSI.JSIExternalCameraSelector.CreateLightCone () [0x00000] in <filename unknown>:0
  at JSI.JSIExternalCameraSelector.OnStart (StartState state) [0x00000] in <filename unknown>:0
  at Part.ModulesOnStart () [0x00000] in <filename unknown>:0
  at Part+<Start>c__Iterator25.MoveNext () [0x00000] in <filename unknown>:0 
 
(Filename:  Line: -1)

in the vab im assuming and these inflight: 

[EXC 22:05:27.839] TargetException: Non-static field requires a target
    System.Reflection.MonoField.GetValue (System.Object obj)
    JSI.JSIMechJeb.AutopilotEnabled ()
    JSI.MechJebRPM.GetActiveMode ()
    JSI.MechJebRPM.UpdateRootMenu ()
    JSI.MechJebRPM.ShowMenu (Int32 width, Int32 height)
    JSI.MonitorPage.get_Text ()
    JSI.RasterPropMonitor.FillScreenBuffer ()
    JSI.RasterPropMonitor.OnUpdate ()
    InternalProp.OnUpdate ()
    InternalModel.OnUpdate ()
    Part.InternalOnUpdate ()
    Part.Update ()

and the data log

TargetException: Non-static field requires a target
  at System.Reflection.MonoField.GetValue (System.Object obj) [0x00000] in <filename unknown>:0
  at JSI.JSIMechJeb.AutopilotEnabled () [0x00000] in <filename unknown>:0
  at JSI.MechJebRPM.GetActiveMode () [0x00000] in <filename unknown>:0
  at JSI.MechJebRPM.UpdateRootMenu () [0x00000] in <filename unknown>:0
  at JSI.MechJebRPM.ShowMenu (Int32 width, Int32 height) [0x00000] in <filename unknown>:0
  at JSI.MonitorPage.get_Text () [0x00000] in <filename unknown>:0
  at JSI.RasterPropMonitor.FillScreenBuffer () [0x00000] in <filename unknown>:0
  at JSI.RasterPropMonitor.OnUpdate () [0x00000] in <filename unknown>:0
  at InternalProp.OnUpdate () [0x00000] in <filename unknown>:0
  at InternalModel.OnUpdate () [0x00000] in <filename unknown>:0
  at Part.InternalOnUpdate () [0x00000] in <filename unknown>:0
  at Part.Update () [0x00000] in <filename unknown>:0 
 
(Filename:  Line: -1)

I also, can not get any of the cameras to show a picture on the screens. I have the full log+data log and ship used if you need it.

      Time of this report: 4/3/2016, 23:06:02
             Machine name: DESKTOP-DT9Q0CO
         Operating System: Windows 10 Pro 64-bit (10.0, Build 10586) (10586.th2_release_sec.160223-1728)
                 Language: English (Regional Setting: English)
      System Manufacturer: ASUS
             System Model: All Series
                     BIOS: 2702
                Processor: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz (8 CPUs), ~4.0GHz
                   Memory: 16384MB RAM
      Available OS Memory: 16258MB RAM
                Page File: 3820MB used, 14869MB available
              Windows Dir: C:\WINDOWS
          DirectX Version: 12
      DX Setup Parameters: Not found
         User DPI Setting: Using System DPI
       System DPI Setting: 96 DPI (100 percent)
          DWM DPI Scaling: Disabled
                 Miracast: Available, with HDCP
Microsoft Graphics Hybrid: Not Supported
           DxDiag Version: 10.00.10586.0000 64bit Unicode
 

You can't use RenderingManager.AddToPostDrawQueue. So @MOARdV will have to fix that. Details on how to fix here in the OP. The reflection on Mechjeb maybe @sarbian changed something so again will have to be looked at.

[sarbian]

hum, I don't think I changed anything that would break that, but then the 1.1 change were extensive. I will break stuff later however since I ll move MJ to a VesselModule soon(-ish)

As for the RenderingManager MOARDV can copy my fix if he want : https://github.com/MuMech/MechJeb2/commit/e0ea8f709db0def1c8029ea6e04ce3a7fc9e4572

[MOARdV]

8 hours ago, JPLRepo said:

You can't use RenderingManager.AddToPostDrawQueue. So @MOARdV will have to fix that. Details on how to fix here in the OP. 

Yeah, I missed that.  I caught that code in Distant Object Enhancement, but forgot it was used here, too.

As for the MechJeb problems - considering there will be large changes in MJ, I am going to hold off on completely fixing that, since it's going to be a moving target until MJ is done.

[MOARdV]

I've updated the dev build on DropBox to fix the crash / errors in the VAB when using JSIExternalCameraSelector (external / docking cameras).  Thanks to @Fwiffo and @toril for reporting that.

As for the MechJeb error: I don't see that with MechJeb dev build 572.  What version are you using?

[toril]

using your new test version again on 1183

 

     Not seeing any errors in the log but the cameras are still nonfunctional all the other displays work flawlessly. Can even see the fov in the vab just nothing on the display, and can't scroll through he attached cameras either.

nothing errors though so not sure what the problem might be.

 

this might be completely bogus but vds hull cam was mentioning the same center of mass fall back that I was experiencing. when they had those cameras installed, but as I can't see through the cameras in rasterprop, I don't know if they are even doing anything.

Edited April 4, 2016 by toril

[MOARdV]

38 minutes ago, toril said:

using your new test version again on 1183

 

     Not seeing any errors in the log but the cameras are still nonfunctional all the other displays work flawlessly. Can even see the fov in the vab just nothing on the display, and can't scroll through he attached cameras either.

nothing errors though so not sure what the problem might be.

 

this might be completely bogus but vds hull cam was mentioning the same center of mass fall back that I was experiencing. when they had those cameras installed, but as I can't see through the cameras in rasterprop, I don't know if they are even doing anything.

Eh, there are probably more things that need changed.  I'm slowly slogging though testing out components, but it's slow going since I've got paying work to do, too.

[toril]

oh no problem.  Not trying to rush you.  Was just hoping to help with error reports as this is one of my favorite mods.

[MOARdV]

23 minutes ago, toril said:

oh no problem.  Not trying to rush you.  Was just hoping to help with error reports as this is one of my favorite mods.

Actually, I broke it when I fixed the VAB part of the camera controls.  The link from previously is now updated with that fix, along with fixes for staging.  Just in time for lunch to be over.

[toril]

ok tested new build 1183 again.  Flight to mun same as last time everything includeing cameras worked flawlessly.  lost power on the way back all the panels died as they are supposed to.  The center of mass never wavered. I would say your set. rpms for scansat and mechjeb also work perfectly, can control mj through jsi panels and see scansat maps.  

[DeputyLOL]

Small issue with the graphing bars, they are purple.

[MOARdV]

40 minutes ago, DeputyLOL said:

Small issue with the graphing bars, they are purple.

Yeah, I saw that.  It's fixed locally, but not updated to DropBox yet.  Probably this evening.

[Fwiffo]

Hey @MOARdV, thanks for so quickly working the bug I reported about crashes in the editor when the FOV marker is shown for a long time.  I tried the 0.25 dev build (DLL modified April 4, 1:28pm PST), but now in the editor I can't get the right-click tweakable context menu to come up for the camera, and the "U" key does nothing.  I tried with both MM 2.6.21 and 2.6.18.  Maybe I'm doing something wrong?

Here's a log in case you ask for it: http://tinyurl.com/FovNoTweakableLog

Also a suggestion - you might consider incorporating into your build process an auto-increment of the last 4 digits ("build #") of the DLL version number, to differentiate between different DEV builds.

One other quick question while I'm here - I noticed the new Readme's since ~0.23.2 don't contain as much detail as they used to.  Is that intentional, or did I miss something?  I've been keeping a copy of the 0.23.2 handy for reference.

Thanks again, really appreciate all your hard work on this great mod!

[MOARdV]

2 hours ago, Fwiffo said:

Hey @MOARdV, thanks for so quickly working the bug I reported about crashes in the editor when the FOV marker is shown for a long time.  I tried the 0.25 dev build (DLL modified April 4, 1:28pm PST), but now in the editor I can't get the right-click tweakable context menu to come up for the camera, and the "U" key does nothing.  I tried with both MM 2.6.21 and 2.6.18.  Maybe I'm doing something wrong?

Here's a log in case you ask for it: http://tinyurl.com/FovNoTweakableLog

Also a suggestion - you might consider incorporating into your build process an auto-increment of the last 4 digits ("build #") of the DLL version number, to differentiate between different DEV builds.

One other quick question while I'm here - I noticed the new Readme's since ~0.23.2 don't contain as much detail as they used to.  Is that intentional, or did I miss something?  I've been keeping a copy of the 0.23.2 handy for reference.

Thanks again, really appreciate all your hard work on this great mod!

The log shows KSP 1.0.5, so I'm not surprised it doesn't work.   Squad's 1.1 changes are not backwards compatible, and 0.25.x is built against KSP 1.1.

The auto-increment system versioning system would be handy, but, from what my experience, it only works with AssemblyVersion, not AssemblyFileVersion.  The 0.25.0 is in the file version; from what I understand, AssemblyVersion is used to determine if interfaces between DLLs are valid.  Changing that value will break mods that provide RPM interfaces (SCANsat, DPAI, etc), which forces those mod authors to update their code (and puts more work on them if they have to do that every time I update).  If I can find an way to automate AssemblyFile numbers, I'll do so.

And the README - oh, yeah, I was including a text file, and I switched to the markdown file instead.  I don't remember why I did that.  I'll merge the two into a single file so I'm less likely to make that mistake again.

Thank you for the feedback - it is extremely helpful to know what I'm doing right and what needs improved.

[Fwiffo]

On 4/5/2016 at 8:03 AM, MOARdV said:

The auto-increment system versioning system would be handy, but, from what my experience, it only works with AssemblyVersion, not AssemblyFileVersion.

If you're interested in this, I made a tiny EXE a long time ago called BuildIncrement which might just do the trick.  Happy to send you the code - it's pretty minuscule, and is triggered by a simple post-build event:

"$(ProjectDir)\BuildIncrement.exe" "$(ProjectDir)\Properties\AssemblyInfo.cs"

If you want it, just send me a PM.

Stackoverflow also has some de-facto approaches described here that might be helpful:

http://stackoverflow.com/questions/826777/how-to-have-an-auto-incrementing-version-number-visual-studio

http://stackoverflow.com/questions/356543/can-i-automatically-increment-the-file-build-version-when-using-visual-studio

Apologies if I misunderstood your explanation and these resources aren't helpful.

>>Squad's 1.1 changes are not backwards compatible, and 0.25.x is built against KSP 1.1.<<

Ah, makes sense.  Will have to revisit once I upgrade (looking forward to getting my feet dirty with 1.1).  Out of curiosity, are you planning to backport any fixes to a 1.0.5 version?

Thanks again.

[MOARdV]

5 hours ago, Fwiffo said:

If you're interested in this, I made a tiny EXE a long time ago called BuildIncrement which might just do the trick.  Happy to send you the code - it's pretty minuscule, and is triggered by a simple post-build event:

"$(ProjectDir)\BuildIncrement.exe" "$(ProjectDir)\Properties\AssemblyInfo.cs"

If you want it, just send me a PM.

Stackoverflow also has some de-facto approaches described here that might be helpful:

http://stackoverflow.com/questions/826777/how-to-have-an-auto-incrementing-version-number-visual-studio

http://stackoverflow.com/questions/356543/can-i-automatically-increment-the-file-build-version-when-using-visual-studio

Apologies if I misunderstood your explanation and these resources aren't helpful.

>>Squad's 1.1 changes are not backwards compatible, and 0.25.x is built against KSP 1.1.<<

Ah, makes sense.  Will have to revisit once I upgrade (looking forward to getting my feet dirty with 1.1).  Out of curiosity, are you planning to backport any fixes to a 1.0.5 version?

Thanks again.

After you'd mentioned it, I did some research of my own, and I determined that I can use the built-in system in VS.  There'll be automatic build numbers going forward.

As for backporting code - no, I won't be.  Supporting two versions of KSP with fairly significant under-the-hood changes is too much of a support burden.