JonnyOThan

Members
  • Content Count

    43
  • Joined

  • Last visited

Community Reputation

77 Excellent

1 Follower

About JonnyOThan

  • Rank
    Rocketeer

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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?
  2. Confirmed: https://github.com/JonnyOThan/RasterPropMonitor/issues/11 Have you tested regular docking too?
  3. 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.
  4. Can you try refreshing the CKAN data and installing it again?
  5. Yep, my mistake...accidentally included a file that shouldn’t be there. Hopefully can get that cleaned up today. Sorry about the inconvenience!!!
  6. RPM v0.31.2 is now available: https://github.com/JonnyOThan/RasterPropMonitor/releases
  7. 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
  8. 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.
  9. 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
  10. 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.
  11. 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.
  12. 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?
  13. 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?
  14. 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
  15. 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.