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

[MOARdV]

I'm assuming so, but I've no idea what it means. And I thought it only right that they should be at least made aware of the problem, if only for reference.

Yeah, recompiling SCANsat means that SCANsat RPM won't link with it (because the DLL is newer / changed). Speaking for myself (since I haven't talked to Mihara about it), we'd have to recompile SCANsat RPM so it'd work with it ... but that might break SCANsat RPM for anyone using the "official" SCANsat. It's a bit of a tough situation - I don't want to maintain two versions of RPM with a single DLL linkage being the only difference, and I definitely don't want to link only to the recompiled SCANsat, since the link to it is buried in the SCANsat thread, which means dealing with support issues when people don't know about it and come here asking why SCANsat doesn't work with us. If SCANsat development really has stopped (which appears to be the case), the best situation would be for someone to pick it up (the license permits this, IIRC) and release an "official" SCANsat Continued that includes the Toolbar integration.

[John FX]

Scansat has not stopped development, it seems the toolbar integration is only a fork at the moment and the fork developer (dmagic) has stopped developing the fork. Damny has not stopped with scansat.

I`m using the official non-toolbar scansat until the official scansat uses toolbar for all the reasons you just said.

Edited April 13, 2014 by John FX

[BudgetHedgehog]

I see... Well, I'll see what we can do in the SCANsat thread. Thanks for the reply!

[SlimeCrusher]

My first reaction to this mod: *Launching a newly designed aircraft* Oooooh! Buttons! *click* *click* *click* Oh look, this one turns on the lights!.. Hmmm lets click some more *click* *click* Most of them are useless... *Looks up* OH CRAP IM TIPPING OVER *Crash*... And after reverting the flight, *CRASH!*, yep the game crashed

Awesome mod! Never thought IVA was so awesome!

[ayana]

I can't even use the default approach indicators anymore after having RPM screens for so long. They're so imprecise compared to a perfect 50 meter rendevouz. And don't even get me started on docking without the closest approach readout, drift is a non-issue using that.

Great work here, so much better than checking the map all the time for "maybe" numbers.

[John FX]

I`m a new fan of RPM. It really adds to the immersion. I only use proc fairings, stretchy tanks, RPM and realchutes for non stock parts really so I thought I would go to the proc fairings and RPM threads and show what I have done with the mods. (stretchy tanks is a bit old but I`m waiting for proc parts to get a bit more stable)

Here is the escape system for Gumdrop, my Apollo replica. As you can see it blocks all view out from the capsule so launch is completely reliant upon cameras and instruments. IVA abort is... interesting.

Javascript is disabled. View full album

and here is a full IVA launch. Check out stage 1 separation at 2:55, the ejection of the escape system at 3:47 and the interstage fairing dropping at 4:50

(full mission)

This mod, along with the others I have mentioned is now on my `I can`t believe it`s not stock` list.

[Mihara]

Here is the new PNG

Thanks, it will be included with the future builds.

Myself I`d like to be able to permanently set `lander` as an object that can be targeted. How could I change the config to do that? (it does not seem to save the setting)

Please tell me the filter list is not hardcoded...

Object type filters are saved per-monitor, and remembered from there on unless anything goes horribly wrong. You cannot configure the default filter state currently, but that's trivial for me to do if you want it -- won't be available until the next release or in the dev build though...

https://drive.google.com/file/d/0BwYzqg0314S0ZTFxdEs3VDAxREk/edit?usp=sharing

Log might be long since thats the entire mission I did but I did save the log from when the smart ass refused to work. Whats happening on my end is when I hit the button for Smart ass is it refuses to do anything but in the debug log it throws out all those null references.

There's a lot of stuff going on in this log, but all of it starts with something called "DarkenSky" dying on start, and every other plugin chokes trying to do things per-part recursively after that, starting with RemoteTech -- RPM is right next. I don't think RPM is at fault here.

Sorry I probably should have explained better. The IVA menu allows me to select celestial bodies however any orbiting ships do not appear under vessels and have to be manually selected from the map if I'm planning to rendezvous. When in vercinity I can see the docking ports etc in the menu, but for some reason selecting them from the IVA doesn't seem to do anything. I'm wondering if maybe I done something wrong somehow actually.

Most likely. There's typically no problem with selecting other orbiting ships from the menu, check the filters in the same menu to see if they're hidden for one reason or another.

Oops, yeah it was the maneuver planner I was thinking of. Figured there was probably a bit more to it with that than some of the other MechJeb options since the maneuver planner covers so many different bases of control.

As of today, RPM can trigger the MechJeb-controlled execution of the planned maneuver, (or rather, a maneuver node, regardless of who made it -- the player, or MechJeb) but cannot trigger MechJeb's functions that create maneuver nodes. It is certainly possible to do, but requires creating another menu to do so, and the biggest stumbling block is numeric entry, the same problem that hinders making a maneuver planner menu -- it's hard to imagine an interface that doesn't suck too hard to use when you actually need to click 3d buttons to control it.

By the way I noticed in the screenshots you have some type of geographical map displayed on some of the screens, is that through some extra mod I've missed somehow? I can't seem to find that tool.

The map is from SCANsat, mentioned in this thread a lot. The plugin to interface to SCANsat is included, so as long as you have scanning sattelites in the game, the map should just magically appear.

It's a bit of a tough situation - I don't want to maintain two versions of RPM with a single DLL linkage being the only difference

If I can figure out how to compile them in a single run without actually maintaining two separate versions of the code, I suppose it's doable, but not otherwise.

Edited April 14, 2014 by Mihara

[Kaa253]

I have to chime in to that smart ass isn't working for me either ( v2.2 mechjeb and .15 rpm). Only mod I have that might be conflicting at all is vessel viewer tho not sure if it would do that or not.

edit: Infact this spammed soon as i clicked the button to go to mechjeb.

http://cloud-4.steampowered.com/ugc/579019453309205712/1A3DC733A6B3B394F2726585ECA0F0A07899CB8C/

...There's a lot of stuff going on in this log, but all of it starts with something called "DarkenSky" dying on start, and every other plugin chokes trying to do things per-part recursively after that, starting with RemoteTech -- RPM is right next. I don't think RPM is at fault here.

...

I am having the same problems. I uninstalled Distant Object which contains "DarkenSky" and got no change with the mechjeb RPM not working. I have uninstalled RemoteTech a long time ago as it is very seriously bugged at present .

My Player.log (Linux) says...

The following assembly referenced from /home/kaa/KSP_linux/GameData/MechJeb2RPM/MechJebRPM.dll could not be loaded:
     Assembly:   MechJeb2    (assemblyref_index=3)
     Version:    2.2.0.0
     Public Key: (none)
The assembly was not found in the Global Assembly Cache, a path listed in the MONO_PATH environment variable, or in the location of the executing assembly (/home/kaa/KSP_linux/GameData/MechJeb2RPM/).

So largely on a whim I moved MechJebRPM.dll into the ~/GameData/MechJeb2/Plugins directory (sitting beside MechJeb.dll) and now it appears to be working correctly excepting that it prints large on screen the message...

"ERROR:MechJebRPM.dll must be in GameData/MechJeb2RPM but it's in GameData/MechJeb2/Plugins"

[mrh]

Mihara, "If I can figure out how to compile them in a single run without actually maintaining two separate versions of the code, I suppose it's doable, but not otherwise." I've never worked with unity code but check out Microsoft Reflection it may help with this:

"The classes in the System.Reflection namespace, together with System.Type, enable you to obtain information about loaded assemblies and the types defined within them, such as classes, interfaces, and value types. You can also use reflection to create type instances at run time, and to invoke and access them. For topics about specific aspects of reflection, see Related Topics at the end of this overview. "

[Mihara]

So largely on a whim I moved MechJebRPM.dll into the ~/GameData/MechJeb2/Plugins directory (sitting beside MechJeb.dll) and now it appears to be working correctly excepting that it prints large on screen the message...

"ERROR:MechJebRPM.dll must be in GameData/MechJeb2RPM but it's in GameData/MechJeb2/Plugins"

Very short answer: Blame Squad and make sure MechJeb is in GameData/MechJeb2 and MechJeb2RPM is in GameData/MechJeb2RPM. Both must be in their specified installation locations for this to work.

Proper answer: This is the Module-That-Must-Not-Be-Named problem. Squad plugin loader does two things horribly wrong:

1. It rejects plugins referencing DLLs which are not currently in memory, regardless of whether they actually call anything in there.
   
2. It makes this decision based on what is currently in memory at the time of plugin loading, and not, say, when all the loading is done -- and it loads files in alphabetical order.
   

Basically this means that if a plugin uses some other plugin it MUST be positioned further down the tree, alphabetically, than the plugins it references. And if these are not present, it won't load at all anyway.

The solution for RasterPropMonitor's API was that other plugins which want to display data on an RPM screen do not actually need to know what RasterPropMonitor is or reference it by name -- they need to present methods that fit a specific pattern and RasterPropMonitor will take care of finding them according to it's configuration and calling them as needed. This lets the author of some other plugin feed data to RPM without actually making their plugin unusable without RPM in the system.

But what if the author of that plugin doesn't care about RPM enough to support it this way, but I want it's data on RPM screens? Then I have to do a shim: A plugin which must fit certain criteria:

1. It MUST be loaded later than both RasterPropMonitor's main assembly (so I can use all the utility code in there) and the plugin it interfaces with RPM.
   
2. It MUST be a separate plugin, so that if that plugin I am interfacing with is not present, that shim will fail to load while RPM will load normally and gracefully pretend it never wanted the data in the first place.
   

This is what the MechJebRPM.dll and SCANsatRPM.dll do. This is why they must be in very specific locations and complain if they aren't -- because people constantly install them incorrectly and then complain to me.

And this is why the plugins they reference must also be in the default installation locations.

P.S. And if your MechJeb2.dll really is in GameData/MechJeb2/Plugins/MechJeb2.dll and it still doesn't work, then the linux build on KSP does not even load everything alphabetically anymore, and all attempts at plugin integration are from here on screwed.

Mihara, "If I can figure out how to compile them in a single run without actually maintaining two separate versions of the code, I suppose it's doable, but not otherwise." I've never worked with unity code but check out Microsoft Reflection it may help with this.

Sorry, it won't. At all. For the reason described above, unless I'm up to reflecting into EVERY SINGLE VARIABLE which will make ScanSat integration much slower than it is.

Edited April 14, 2014 by Mihara

[John FX]

You cannot configure the default filter state currently, but that's trivial for me to do if you want it -- won't be available until the next release or in the dev build though...

I`d happily run a dev build if it had a way of setting the default filter state. It would come in very handy for my Apollo replica where I stage then try to dock with the lander...

Although things are much easier now I know to change sorting with the circle button. TYVM

Glad to help with the PNG, feel free to change the black dot to a red light, blue stripe or whatever if you want.

[Kaa253]

P.S. And if your MechJeb2.dll really is in GameData/MechJeb2/Plugins/MechJeb2.dll and it still doesn't work, then the linux build on KSP does not even load everything alphabetically anymore, and all attempts at plugin integration are from here on screwed.

Thank you for the comprehensive answer. I really appreciate you taking time to explain it.

If/when the 2 dll are on the correct paths then it is not working for me.

I do see assemblies loading in alphabetical order so there is hope that all is not screwed.

However, I am not sure what I am seeing! It looks like the assemblies load in correct order at game launch and then around the time the menu appears for some reason the Player.log file is getting deleted and started afresh. The new Player.log starts with the RPM dll failing to find MechJeb and it seems that a bunch of dlls are then getting loaded for a second time. Why this is going on I don't know but I do have a lot of mods and one or two are not behaving well. I think the restart of logging is in itself indicating something wrong with my modded KSP. That odd restart of the logging makes it pretty difficult to diagnose. I am a bit too tired to chase it further tonight. I am waiting for a couple of mods to release 0.23.5 versions. Perhaps these updates will make a difference. Otherwise I should be able to look at this again come the weekend. Armed with what I have learned from your "proper" answer I might be able to figure it out then.

[John FX]

Thank you for the comprehensive answer. I really appreciate you taking time to explain it.

If/when the 2 dll are on the correct paths then it is not working for me.

I do see assemblies loading in alphabetical order so there is hope that all is not screwed.

However, I am not sure what I am seeing! It looks like the assemblies load in correct order at game launch and then around the time the menu appears for some reason the Player.log file is getting deleted and started afresh. The new Player.log starts with the RPM dll failing to find MechJeb and it seems that a bunch of dlls are then getting loaded for a second time. Why this is going on I don't know but I do have a lot of mods and one or two are not behaving well. I think the restart of logging is in itself indicating something wrong with my modded KSP. That odd restart of the logging makes it pretty difficult to diagnose. I am a bit too tired to chase it further tonight. I am waiting for a couple of mods to release 0.23.5 versions. Perhaps these updates will make a difference. Otherwise I should be able to look at this again come the weekend. Armed with what I have learned from your "proper" answer I might be able to figure it out then.

If I were getting issues like this I would suspect corruption. I would create a fresh install of KSP in a separate directory and add ARM then install just Mechjeb and see if it worked, then just RPM and see if that worked. At this point you know for sure whether the two mods work on a fresh install on your machine (I see MJ has some issues with the latest dev build for example) then install both together to see if MJ was visible on RPM.

At this point, if they do not work, upload your log. I would say upload it here and in the MJ thread.

If they *do* both work then either it was an installation issue, corruption, or a third mod is messing with them and you need to identify that. Install the rest of your mods one by one, testing RPM and MJ until something breaks.

If nothing breaks and you have reinstalled everything then you were a victim of corruption or an installation issue.

[Moon Goddess]

Does this have an incompatibility with Hullcam VDS?

After installing RasterProp the cameras from Hullcam VDS now work as IVA cameras which is great but lose their original function. So now, there is no way to use the camera on a probe or any craft without an IVA, and there is no way to use both camera's of the booster camera. It would be really great to have both functions.

[John FX]

Does this have an incompatibility with Hullcam VDS?

After installing RasterProp the cameras from Hullcam VDS now work as IVA cameras which is great but lose their original function. So now, there is no way to use the camera on a probe or any craft without an IVA, and there is no way to use both camera's of the booster camera. It would be really great to have both functions.

There is an interesting plugin that uses RPM which may interest you.

It`s an IVA control room for controlling unmanned probes with RPM...

You can use your cameras and everything AFAIK.

http://forum.kerbalspaceprogram.com/threads/67450

i`m not sure what stage it is in development but it seems just what you need in the mean time.

[Moon Goddess]

Yeah I've seen that, it's cool but not exactly what I'm seeking here.

[John FX]

Yeah I've seen that, it's cool but not exactly what I'm seeking here.

I know, the best solution would be the mods playing better with each other. I just thought it might be an interim solution to let you see from your cameras on your unmanned flights. I`ve just downloaded it myself for the first time so I will see how good it is now (If I am saying to people to get it I should have tried it myself)

[Dogoncrook]

If I were getting issues like this I would suspect corruption. I would create a fresh install of KSP in a separate directory and add ARM then install just Mechjeb and see if it worked, then just RPM and see if that worked. At this point you know for sure whether the two mods work on a fresh install on your machine (I see MJ has some issues with the latest dev build for example) then install both together to see if MJ was visible on RPM.

At this point, if they do not work, upload your log. I would say upload it here and in the MJ thread.

If they *do* both work then either it was an installation issue, corruption, or a third mod is messing with them and you need to identify that. Install the rest of your mods one by one, testing RPM and MJ until something breaks.

If nothing breaks and you have reinstalled everything then you were a victim of corruption or an installation issue.

I have the dev version of mechjeb, and the latest rpm, using 0.23.5, and I get autopilot not loaded. Downloaded again and made sure all the files and folders are where they should be. I figure it won't work till mech is up to date, but it seems like your saying that it should work anyways? Here are the errors I get.

Cannot finmodule "MechjebRPMVariables"

Cannot find internal module "MechjebRPM"

and then a bunch about mechjeb buttons.

Edit: disregard the buttons part that's only happens in the alcore pod.

Edited April 16, 2014 by Dogoncrook

[Moon Goddess]

I know, the best solution would be the mods playing better with each other. I just thought it might be an interim solution to let you see from your cameras on your unmanned flights. I`ve just downloaded it myself for the first time so I will see how good it is now (If I am saying to people to get it I should have tried it myself)

Yeah, I'm sorry if I came across rude there.

I guess I have like different goals from the mods. RPM is great for when I'm wanting to experience the I'm right there in the pod feeling.

Hullcam, gives me great angles for screenshots and movie-like angles.

But yeah you offered a great alternative, and I've downloaded it gonna try it out, I should have been more polite.

[koksny]

Do i have to download some additional part with internals for PorkWorks Habitat Pack? Atm game crashes after loading craft that includes Porkworks Orbital Orb (with RPM installed). Log below:

[LOG 06:54:45.910] Cannot find InternalPart 'orbitalOrbInternalsRPM'

[EXC 06:54:45.911] ArgumentException: The thing you want to instantiate is null.

After it everything just goes full kraken. Am i missing something, or did 0.23.5 broke compatibility? (did not had that problem in last version between Habitat Pack and RPM)

[OrbitalDebris]

I didn't include logs when I posted earlier about MJ no longer working. This is what the relevant part of KSP.log looks like:

[ERR 23:51:42.903] AssemblyLoader: Exception loading 'MechJebRPM': System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded.
  at (wrapper managed-to-native) System.Reflection.Assembly:GetTypes (bool)
  at System.Reflection.Assembly.GetTypes () [0x00000] in <filename unknown>:0 
  at AssemblyLoader.LoadAssemblies () [0x00000] in <filename unknown>:0 

Additional information about this exception:

 System.TypeLoadException: Could not load type 'MechJebRPM.MechJebRPM' from assembly 'MechJebRPM, Version=0.15.5213.34967, Culture=neutral, PublicKeyToken=null'.

 System.TypeLoadException: Could not load type 'MechJebRPM.MechJebRPMVariables' from assembly 'MechJebRPM, Version=0.15.5213.34967, Culture=neutral, PublicKeyToken=null'.

 System.TypeLoadException: Could not load type 'MJMenu' from assembly 'MechJebRPM, Version=0.15.5213.34967, Culture=neutral, PublicKeyToken=null'.

This was the same error I saw with the previous release version of RPM, but the prerelease version I tried a few days ago fixed it. Did that fix get accidentally reverted in the current release version?

[Mihara]

After installing RasterProp the cameras from Hullcam VDS now work as IVA cameras which is great but lose their original function. So now, there is no way to use the camera on a probe or any craft without an IVA, and there is no way to use both camera's of the booster camera. It would be really great to have both functions.

Wait-wait-wait, what exactly do you mean by 'lose their original function'? I certainly did not remove it. In what fashion exactly do they lose it?

I have the dev version of mechjeb, and the latest rpm, using 0.23.5, and I get autopilot not loaded. Downloaded again and made sure all the files and folders are where they should be. I figure it won't work till mech is up to date, but it seems like your saying that it should work anyways? Here are the errors I get.

The current release, 2.2, and dev versions released subsequent to that, should be compatible. Which particular version have you got?

Do i have to download some additional part with internals for PorkWorks Habitat Pack? Atm game crashes after loading craft that includes Porkworks Orbital Orb (with RPM installed). Log below:

Orbworks internal is patched in like this:

INTERNAL
{
	name = orbitalOrbInternalsRPM
	MODEL
	{
		model = PorkWorks/Spaces/orbitalOrbInternals/model

....


@PART[*]:HAS[@INTERNAL[orbitalOrbInternals]]
{
	MODULE
	{
		name = RasterPropMonitorComputer
	}
	@INTERNAL
	{
		@name = orbitalOrbInternalsRPM
	}
}

Which translates into "create a new internal that uses the base model located at 'PorkWorks/Spaces/orbitalOrbInternals/model'" and "patch that new internal into every pod that previously used 'orbitalOrbInternals'".

If orbitalOrb is not found in the specified location but is found somewhere else, it's new internal is "orbitalOrbInternalsRPM" but that internal itself could not be loaded, because the model for it is not in "PorkWorks/Spaces/orbitalOrbInternals/model". Did the standard installation location change or did you change it and put it somewhere else?

[Kaa253]

@ John FX. Thanks for the plan to follow for the diagnosis of my problem, I will follow it when I have a chance.

@ koksny. My copy of Porkworks Orbital Orb with RPM installed is not generating a game crash and its RPMonitors appear to be working correctly (aside from the almost certainly unrelated MechJeb issue)

[koksny]

Which translates into "create a new internal that uses the base model located at 'PorkWorks/Spaces/orbitalOrbInternals/model'" and "patch that new internal into every pod that previously used 'orbitalOrbInternals'".

If orbitalOrb is not found in the specified location but is found somewhere else, it's new internal is "orbitalOrbInternalsRPM" but that internal itself could not be loaded, because the model for it is not in "PorkWorks/Spaces/orbitalOrbInternals/model". Did the standard installation location change or did you change it and put it somewhere else?

Ah, then i see where might be problem. You see, Porkjet changed recently directory name to "HabitatPack", it's no longer "PorkWorks", i guess that's the reason of kraken unleashing the moment i load Orb. Going to check it out, but i'm pretty sure that is related.

@ John FX. Thanks for the plan to follow for the diagnosis of my problem, I will follow it when I have a chance.

@ koksny. My copy of Porkworks Orbital Orb with RPM installed is not generating a game crash and its RPMonitors appear to be working correctly (aside from the almost certainly unrelated MechJeb issue)

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)?

[Moon Goddess]

Wait-wait-wait, what exactly do you mean by 'lose their original function'? I certainly did not remove it. In what fashion exactly do they lose it?

(Not sure exactly what you know and don't, so summing up all)

Installing Hullcam VDS without RPM adds a series of part 'cameras', each of these 'cameras' offer a right click menu option for "Activate Camera" when you do this the camera takes over full screen same as any other game camera (auto, chase, iva, etc.) One of these 'cameras' is a booster cam, it offers 2 camera views both 'up' and 'down'.

So after adding RPM, all of these 'camera' parts are added the right click options to change their id. for use in RPM. Which is great. However, the option for "Activate Camera" no longer shows on the right click menu, and the booster cam only offers 1 id so only the 'up' view is usable.