[0.25] RasterPropMonitor - putting the A in your IVA (v0.18.3) [8 Oct]

[BudgetHedgehog]

I don't bother with the Activate Camera bit, I just press + or - until I get to the shot I want. Delete brings me back to normal view (though I keep meaning to change it due to Abort conflicts). I know in the VAB at least, the two-cam booster cam acts as 1 cam - there's only one set of ID+/- and one FOV cone.

[Moon Goddess]

So + and - will cycle thru Hullcam camera's the way V cycle's thru stock cameras?

Do I need to use the ones by backspace or the ones on number pad? I've never tried it that way.

[BudgetHedgehog]

So + and - will cycle thru Hullcam camera's the way V cycle's thru stock cameras?

Do I need to use the ones by backspace or the ones on number pad? I've never tried it that way.

Yes to the first question, and the ones by the backspace to the second.

[montyben101]

Im getting a really annoying error message which wont go:

edit: ignore jeb looking weird, thats just fasa launch clamps

Edit: its linked with KSO shuttle were i got rid of some of the parts, strange since i didnt touch the MFD folder from fear of messing things up

Edit: at least just tell me how to dismiss the error since nothing is wrong, at least that i can see

Solved

Edited April 16, 2014 by montyben101

[Dogoncrook]

@mihara I'm using rpm 15 and mechjeb dev 222.

[Moon Goddess]

Well, After doing the + - thing, now the activate camera on right click reappears... *shrug*

Thanks.

[OrbitalDebris]

@mihara I'm using rpm 15 and mechjeb dev 222.

Yep, me too.

[Kaa253]

Out of curiosity and to prove thesis from above - what is the name of your Pork-stuff directory? Do you still use the old upload by any chance (Without the new FLAT)?

koksny. Obviously you are on to it as you have indeed surmised correctly, I have the old PorkWorks directory. Sorry if I was the source of any misdirection and thank you for alerting me that my copy of HabitatPack is not up to date.

[Kaa253]

Following John FX's suggested procedure I have installed a clean version of Linux 64 KSP 0.23.5 with only MechJeb. There are no errors and MechJeb works correctly (albeit without toolbar support). I then added only RPM, no other mods at all. At this point I find that the MechJebRPM assembly is failing. I added ScanSat to the install simply to demonstrate that the ScanSatRPM assembly does launch correctly.

Player.log from this state is here https://drive.google.com/file/d/0BzLgvasHaJvPdHRrQzNGTmpKSWc (I hope the link works, its my first attempt to use Google Drive)

Everything in the log file looks pretty normal to me except the MechJebRPM related errors appearing around lines 142-167.

Mihara, I really appreciate the great work you are doing on this mod. Be aware that I am in no particular hurry for an answer to this. In your own time please, take as long as you like. Possibly that is forever if you don't necessarily support the Linux version.

And have a very Happy Easter to everyone.

[OrbitalDebris]

I've also created a minimal install of KSP by copying my Steam version into its own directory and deleted all mods except MM, the toolbar, MJ and RPM. My output_log.txt file is at https://onedrive.live.com/redir?resid=962FD212EEE06DAC!11866&authkey=!AOb9Qs4AWZDQpK0&ithint=file%2c.txt. Hopefully having both Linux 64 bit and Windows 32 bit logs should help. Let me know if you need anything else, I'm handy with a debugger but I've never compiled KSP code/mods before.

[John FX]

I have done some testing and I cannot get MJ Dev 222 on a monitor on RPM. The last build I have tested that works fine is 217

I suggest rolling your Mechjeb back to 217 until the next dev build of RPM.

It seems more and more these days that as people release dev versions that break compatibility with other mods almost daily that mod makers should put which version of the other mods their mod works with (hope that makes sense, not had first coffee yet).

Currently MJ dev build 217 is confirmed OK.

Dev build 218 does not work yet

for people skimming the thread...

IF YOU CANNOT SEE MECHJEB ON YOUR MONITORS AND YOU ARE USING RPM 0.15 THEN MAKE SURE YOU HAVE MECHJEB DEV BUILD 217

Edited April 18, 2014 by John FX

[DasBananenbrot]

I have done some testing and I cannot get MJ Dev 222 on a monitor on RPM. The last build I have tested that works fine is 217

I suggest rolling your Mechjeb back to 217 until the next dev build of RPM.

It seems more and more these days that as people release dev versions that break compatibility with other mods almost daily that mod makers should put which version of the other mods their mod works with (hope that makes sense, not had first coffee yet).

Currently MJ dev build 217 is confirmed OK.

Dev build 218 does not work yet

for people skimming the thread...

IF YOU CANNOT SEE MECHJEB ON YOUR MONITORS AND YOU ARE USING RPM 0.15 THEN MAKE SURE YOU HAVE MECHJEB DEV BUILD 217

Oh thanks (10char)

[Moon Goddess]

Speaking of getting Mechjeb into RPM.... is there such thing as a screen the in any way replicates MechJeb's delta-V stats screen? It's the only screen I can't seem to get rid of, I need to know how much fuel I have left in each of my stages.

[John FX]

Your remaining Dv for the current stage is shown on one of the screens, possibly orbit.

Does anyone know how to change the field of view of the cameras?

Either to change the FOV permanently for all cameras or for a particular camera already on a craft?

[ayana]

Your remaining Dv for the current stage is shown on one of the screens, possibly orbit.

The one on the orbit screen is the delta-V for your next maneuver node.

[John FX]

The one on the orbit screen is the delta-V for your next maneuver node.

Then the remaining Dv for the current stage is on a different screen. I know it is on one of them.

You could have said which screen it *was* on you know...

EDIT : It`s the `info` screen. Number 4.

Edited April 20, 2014 by John FX

[ayana]

Mine doesn't have that. But I don't have Mechjeb either, so that's probably why.

[BudgetHedgehog]

Mine doesn't have that. But I don't have Mechjeb either, so that's probably why.

Yeah, RPM takes the dV stats from MJ so you'd need it to see them.

[John FX]

Well you learn something new each day so they say. I didn`t know that.

Does anyone know how to change the field of view on the cameras?

[Mihara]

Bump for new release. Sorry, ladies and gentlemen, I really have my hands full right now.

RasterPropMonitor v0.16

This is a maintenance release, released early because MechJeb's version number changed yet again. This version now requires MechJeb version 2.2.1 or a subsequent development build that still has this version number. (0.15 was compiled for 2.2.0).

Bugs fixed

• Courtesy of John FX, the provided camera model now has a marking on it allowing you to tell where the top side is.
  
• textOverlay option would obey localMargins, when the intent was specifically that it would not do so.
  
• Paths for the Orbital Orb patch have been corrected to conform to the new installation locations.
  

New features

• It is now possible to change the default filter mask for JSITargetMenu. The default has been changed to include landers.
  

P.S. At the time of writing, "version 2.2.1" corresponds to dev build numbers of MechJeb between 224 and 230 inclusive. I did not test with dev builds, but unless they changed version numbering completely out there, it should work with all of them. I definitely tested it to be compiled for 2.2.1.

I am not planning to support the toolbar-ified version of SCANsat for the simple reason that it's quite cumbersome to support both versions of the DLL at once. Pester damny to include the changes or... well, or don't.

Edited April 20, 2014 by Mihara

[John FX]

Bump for new release. Sorry, ladies and gentlemen, I really have my hands full right now.

RasterPropMonitor v0.16

This is a maintenance release, released early because MechJeb's version number changed yet again. This version now requires MechJeb version 2.2.1 or a subsequent development build that still has this version number. (0.15 was compiled for 2.2.0).

Bugs fixed

• Courtesy of John FX, the provided camera model now has a marking on it allowing you to tell where the top side is.
  
• textOverlay option would obey localMargins, when the intent was specifically that it would not do so.
  
• Paths for the Orbital Orb patch have been corrected to conform to the new installation locations.
  

New features

• It is now possible to change the default filter mask for JSITargetMenu. The default has been changed to include landers.
  

P.S. At the time of writing, "version 2.2.1" corresponds to dev build numbers of MechJeb between 224 and 230 inclusive. I did not test with dev builds, but unless they changed version numbering completely out there, it should work with all of them. I definitely tested it to be compiled for 2.2.1.

I am not planning to support the toolbar-ified version of SCANsat for the simple reason that it's quite cumbersome to support both versions of the DLL at once. Pester damny to include the changes or... well, or don't.

Thank you very much, especially for the target filter options.

I noticed MJ went through 4, yes four, dev versions in a *single day* a couple of days ago...

It`s just not possible to keep up with so many changes.

I`ll have a poke about and post the last working dev version I can get on a RPM monitor.

EDIT : I can confirm the latest official release of Mechjeb (2.2.1) on Spaceport works fine with RPM.

I then tested Dev #230 and it DOES NOT work with RPM 0.16

I tested Dev #227 and it DOES NOT work with RPM 0.16

I tested Dev #226 and it DOES NOT work with RPM 0.16

For completeness I tested Dev #225 and it DOES NOT work with RPM 0.16

I got worried then so I reinstalled the official 2.2.1 and it worked fine so I left it there.

It seems the official version 2.2.1 is the only version that works. DO NOT USE DEV VERSIONS OF MECHJEB WITH RPM 0.16

disclaimer : this is not suggesting RPM needs updating, you do enough already. This is purely for information and hopefully to save you answering questions for a few hours

Edited April 20, 2014 by John FX

[Mihara]

Well, that means they changed version numbering so that the stable release is the last build that gets a particular version number, rather than the first, as it was previously. (You can confirm or deny that by checking the version number for dev builds in Windows file properties.) Which means RPM can be compatible with the release or with the dev builds, but not both.

I don't think .NET lets me bypass that easily.

EDIT: Well, it's actually worse. Dev builds now have a version number of 2.2.1.<build number>, which means that there will be no more compatibility with dev builds unless someone tells me how to bypass that.

Edited April 20, 2014 by Mihara

[John FX]

I thought there was something odd when build 225 did not work but the official build which was exactly the same did...

Maybe Mechjeb could build some form of standardized interface (Is it an API?) to allow other mods to control it which would not break with every dev build?

[sarbian]

Mihara I don't see why the change in version number can impact RPM

I noticed MJ went through 4, yes four, dev versions in a *single day* a couple of days ago...

It's called a dev version... Each time we change something a new version is automaticly released. If you don't want change use the stable one.

[Mihara]

Maybe Mechjeb could build some form of standardized interface (Is it an API?) to allow other mods to control it which would not break with every dev build?

It's more complicated than that, and as far as I can tell it's mostly due to the Module-That-Must-Not-Be-Named problem which I mentioned previously.

The elements of MechJeb which RPM accesses changed little since MechJeb 2.0 appeared -- RPM's interface shim just accesses public members of MechJeb's classes directly, reaches into the guts and tugs on them. This is exactly how it (and most other plugins that do anything fun) treats KSP itself, that's what amounts for API around here, and it usually works. RPM's code that does so did not ever change because MechJeb explicitly broke it by removing or renaming those public members, because MechJeb never did such a thing in all the time MechJebRPM existed. MechJeb's code per se is, therefore, not at fault. All that should be required for MechJebRPM to load is to for MechJeb's DLL to be available, i.e. for those members to exist, be named the same, and ask for the same number of parameters if they're a method that needs to be called.

The Module-That-Must-Not-Be-Named problem adds one restriction -- MechJeb's DLL must be loaded first, otherwise KSP's plugin loader throws things that require it out. That should not make a specific version required either. In C#, there is such a thing as a 'strongly named assembly' which would explicitly prevent calling the wrong version of the DLL, but that requires the latter to be cryptographically signed. As far as I can tell, nobody in the KSP plugin world does this, which means that the requirement for a specific version to be referenced comes from KSP's plugin loader. Either that, or there's a compilation option I'm totally not aware of.

The only option of dealing with it is rewriting lots of code, because I'll need to use the so-called 'reflection', which in this case will basically amount to telling KSP, "I'm not allowed to call this module, or use it's data structures or whatever, but here's a string that contains it's name. Find me something that has this name, is of this type, has these and these parameters, and give me a pointer so I can finally call it dammit."

RPM does it for things that plug into RPM, and it's easy enough, because in this case it's RPM who gets to say "If you want to plug into me, you have to have an object that looks like so and so, and tell me it's name, I'll call you if I need anything.", so it can be done in a more or less generic way, once. It proved so handy (because it lets monitors be configurable in a generic way regardless of whether a handler is internal to RPM or not) that RPM even calls it's own internal components the same way. Doing this to access all the variety of things RPM currently does with MechJeb would be quite a pain, if only because the best way of doing this that I know so far allows me to only communicate objects of types that are already defined, either by C# or by KSP itself.

Well, either that or MechJebRPM gets merged into MechJeb, which would avoid the module-that-must-not-be-named problem entirely, but that, I expect, is not practical.

Mihara I don't see why the change in version number can impact RPM

But as far as anyone can tell it does. Unless I'm horribly wrong (which I'm sure someone will eventually point out) you have to ask Squad's plugin loader why is it so silly.

Edited April 20, 2014 by Mihara
small corrections.