JonnyOThan

That’s interesting, because there is definitely a crash inside RPM code when this happens. I had a sneaking suspicion that it might be a problem in the base game as well because I’ve seen weird behavior when docking with a claw and the internal camera, even without RPM installed. Does regular docking have any issues when in IVA with (or without) RPM?

Confirmed: https://github.com/JonnyOThan/RasterPropMonitor/issues/11 Have you tested regular docking too?

If you dig through the AirplanePlus thread you can find a number of IVAs people have made. Just search for "IVA" or "RPM" within the thread itself.

Can you try refreshing the CKAN data and installing it again?

Yep, my mistake...accidentally included a file that shouldn’t be there. Hopefully can get that cleaned up today. Sorry about the inconvenience!!!

RPM v0.31.2 is now available: https://github.com/JonnyOThan/RasterPropMonitor/releases

I just released RPM v0.31.2. You can get it here. Changes: CKAN is now officially supported. There are 2 CKAN packages, see the readme for details. Fix KOSPropMonitor not refreshing the screen properly Fix orbit display icon rendering Fix vessel recovery prop soft-locking the game in some circumstances Add missing vessel types to target menu Fix some debug-only errors Fix null reference exception on revert to editor Add compatibility patches for incorrectly configured mods (NMB and OPT specifically) Fix null reference exception when using internal light switch on incorrectly configured cockpits External camera pages default to skip missing cameras, so the ALCOR MFD landing page will start on ExtCam1 if it exists Move variable handler for plugins before builtins like it says in the docs Fix line drawing on NAV pages due to broken shader reference in scansat

Yeah, I’ve been in contact with them on the kerbalism discord about this. Still trying to settle on the best method. It might end up requiring small code changes on both sides, so I wouldn’t hold my breath for a fix anytime soon.

I've confirmed the issue, though it might not affect you much. The EC *levels* are correct, but the "flow rate" for various sources displayed in a specific prop will not be correct if you are using Kerbalism. Details here: https://github.com/JonnyOThan/RasterPropMonitor/issues/4

Hi! I'm the new maintainer of RPM and I'm doing an audit of mods that use it. Is this mod still being maintained? There are a number of issues with its use of RPM. I could provide a MM patch to fix them but it'd be best if they were just fixed in the actual package. space\f-18c.cfg contains a RasterPropMonitorComputer module. This is incorrect - RasterPropMonitorComputer is a PartModule and needs to go in the part config, not an InternalModule props\nmb_hud4.cfg also contains a RasterPropMonitorComputer and it shouldn't None of the command parts themselves contain a RasterPropMonitorComputer module and they should. Many things will appear to work without this, but some things don't.

Eh, I’d just as soon include it as a patch within RPM itself. There are IVAs provided for some other cockpit mods within the RPM package, so that kind of interconnection has a precedent. There are probably other mods like NMB and more that have the same or similar problems and I’d prefer to just deal with them all the same way. I can set this up in a way that it only applies to parts that are set up incorrectly, so that if you decide to provide a patch that fixes some or all of them it should just work. One thing that a lot of people do, for example, is provide a custom boot screen for the MFD that shows the name & version of the IVA itself.

This is quite interesting. As I mentioned - many of the RPM props will try to add the RPMComputer if there isn’t one. But the way that it does it doesn’t quite work, which is why the error messages are emitted and the SAS hold buttons don’t work. This has to do with what functions get called during object creation, so it might have changed in the unity upgrade in 1.8 - but that’s just speculation. It also might vary by cockpit depending on the ordering of the props in the internal model. I’ve also learned that its not a great idea to add part modules at runtime, so even though I think it would be possible to alter how the RPMComputer is created I don’t think that’s the best fix. It should be the responsibility of the part mod to get their cfg files correct, but I don’t think OPT is getting updates anymore. So I can provide a MM patch to fix this in the next release. I could do it for all parts that have internal models, but that seems a little heavy-handed. So I think I will narrowly scope it only to the mods that I know have this problem. Finally, what’s NMB?

Works fine for me, but I don't usually use the in-game text editor. Are you familiar with the different storage volumes for scripts?

Many RPM props will create the RasterPropMonitorComputer module if it doesn't exist. Did adding the module manually fix the problem? Which cockpits were you using? The message "Tried to look for method with propToUse still null?" is emitted by the RasterPropMonitorComputer itself, so I don't see how adding that could have fixed it. EDIT: I've managed to repro this one. It seems benign, but I'll try to figure it out. Fixed - this was benign, but good to clear out stuff that might look like a red herring: https://github.com/JonnyOThan/RasterPropMonitor/issues/9

The BCockpit and ILSCockpit versions that use RPM don't seem to actually be referenced anywhere. The mk23 cockpit seems to only have the RPM version. I enabled the first two with a simple patch, but maybe this should get rolled into the official package: @PART[*]:HAS[@INTERNAL[BCockpit]]:NEEDS[RasterPropMonitor] { MODULE { name = RasterPropMonitorComputer } @INTERNAL { @name = BCockpit_rpm } } @PART[*]:HAS[@INTERNAL[ILSCockpit]]:NEEDS[RasterPropMonitor] { MODULE { name = RasterPropMonitorComputer } @INTERNAL { @name = ilsCockpit_rpm } } Adding the RasterPropMonitor module isn't strictly necessary because many of the RPM props will create one if it doesn't exist. Never mind, apparently adding modules at runtime should be avoided, so it's better to add it via MM config like this.

I’ve updated RPM for 1.8 here, but the camera selector crash won’t be fixed until the next release (v0.31.1)

This has been an issue in RPM forever (and other mods that do vessel recovery like KRPC). I have a fix for the next release.

I really don’t mind huge logs - I have good tools for parsing and searching. If you want you can zip it; they usually compress really well. I don’t think there’s any reason CKAN wouldn’t work. But there is a bug in scansat (see earlier posts in this thread). And make sure you get “VesselViewerContinued” (not kronal vessel viewer) AND the RPM integration package for it. If you’re still having problems, the log file will tell me exactly what you have installed and what might be going wrong.

Hm, I was using 18.14 when I hit that trailMaterial issue. It may be that you won't hit it in certain situations, like if you don't have a target or if it's not trying to draw a ground track.

Interestingly, this is an issue with every single mod I've seen that tries to provide vessel recovery. It will be fixed in the next release: https://github.com/JonnyOThan/RasterPropMonitor/commit/daabffa54b56a9ab26192ca1144fd9efce2baded I need your *entire* ksp.log. I can’t do anything with just this snippet because I use IVAs with ASET props and don't hit this problem. Also reporting which IVA you are using would help.

Please don't try to hack it together, it should work as-is. Did you maybe download the source code zip instead of the release zip? That would explain the missing DLL. The release zip contains ONLY a GameData folder, which in turn contains a JSI folder. The JSI folder needs to go inside your KSP's GameData folder. EDIT: Actually, if the error message is telling you that it needs to go into JSI/Plugins then the error message itself is incorrect - it should be JSI/RasterPropMonitor/Plugins/RasterPropMonitor.dll. I'll fix that. EDIT 2: I checked the code and it's correct, you must have copied the path down wrong.

I'm getting the same "can't click on anything" and constant errors spammed with nothing but Kerbalism, ModuleManager, and CommunityResourcePack installed and a brand new sandbox save. I installed Kerbalism 3.2 from spacedock and CRP 1.3.0 from github. Logs here: https://drive.google.com/file/d/1ttDp_0JcPcB7UKZVPc4cNi3aCGvP9Aq0/view?usp=sharing EDIT: well this is embarrassing....I failed to install one of the kerbalism configs. Still, it would be nice if there was some kind of alert when this happens! The first error is here, presumably because there is no Kerbalism.cfg file: [EXC 10:19:40.195] IndexOutOfRangeException: Index was outside the bounds of the array. KERBALISM.Settings.Parse () (at <d0c64642e7b34b419c7638a19618d36d>:0) KERBALISM.Loader.Start () (at <d0c64642e7b34b419c7638a19618d36d>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object)

I've seen reports of similar issues that have nothing to do with RPM. This can also happen if you're in timewarp or if you have the mouse over a window that wants to eat input. Please at least include your ksp.log file if you expect support.

I copied most of that from MOARdV's original post. I've been working with the CKAN folks (Hi @HebaruSan!) and it'll be officially supported on the next release.

The collider for the staging prop here can sometimes obstruct the PREV and STBY buttons on the MFD. I accidentally staged when I wanted to change external cameras