Jump to content

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


Mihara

Recommended Posts

I know that this happens when the plugin failed to load so hard that it can't even tell you why exactly. (Which it usually does, loudly, when it didn't fail that hard.)

I also know that in every case that I have investigated so far, it turned out to be an installation error, which is why I usually stay quiet, since to tell you where it is exactly requires puzzling through megabytes worth of KSP_Data/output_log.txt and there's only so many times I can do that before it gets old.

Here's my log if you need it.

Link to comment
Share on other sites

Mihara. If you get some time, please take a look at post #1333 on this thread and the follow up discussion. It seems the data for delta angles and distances are not displaying the correct values in the docking camera. I've tried with all the different versions of RPM and also tested it with the lazer docking cam addon installed for comparison. (Lazer docking cam works correctly) Probably not an issue for most people since they just use autopilots but I thought I would mention. (Just FYI)

I've heard this complaint before. Nobody has, so far, been kind enough to explain to me just what the formula should be, and between what and what the angles should be measured. I'm not a mathematician, I'm a sociologist. :)

Link to comment
Share on other sites


Failed to load assembly C:\Program Files (x86)\Steam\SteamApps\common\Kerbal Space Program\GameData\Kethane\Plugins\MMI_Kethane.dll:
System.BadImageFormatException: Format of the executable (.exe) or library (.dll) is invalid.

...

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.16.5223.32098, Culture=neutral, PublicKeyToken=null'.

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

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

(Filename: C:/BuildAgent/work/d3d49558e4d408f4/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 53)

AssemblyLoader: Exception loading 'TweakableAnimateGeneric': 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 'TweakableEverything.ModuleTweakableAnimateGeneric' from assembly 'TweakableAnimateGeneric, Version=1.2.5263.29756, Culture=neutral, PublicKeyToken=null'.

(Filename: C:/BuildAgent/work/d3d49558e4d408f4/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 53)

Your Kethane, TweakableAnimateGeneric, TweakableLadders are not getting loaded for whatever reason. The recommendation is updating them or deleting them if you can't update. (They aren't working anyway.) This is probably not the problem, because...

MechJebRPM is getting both-loaded-and-not-loaded as I described about fifty posts above. (Blame Squad and their braindead plugin loader.) Either delete MechJebRPM.dll or make sure that the version of MechJeb that you have installed is the latest official release version, development versions do not work. This is a known problem which caused much argument in the past and everything will return to working once RPM 0.17 is released.

Link to comment
Share on other sites


Failed to load assembly C:\Program Files (x86)\Steam\SteamApps\common\Kerbal Space Program\GameData\Kethane\Plugins\MMI_Kethane.dll:
System.BadImageFormatException: Format of the executable (.exe) or library (.dll) is invalid.

...

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.16.5223.32098, Culture=neutral, PublicKeyToken=null'.

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

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

(Filename: C:/BuildAgent/work/d3d49558e4d408f4/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 53)

AssemblyLoader: Exception loading 'TweakableAnimateGeneric': 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 'TweakableEverything.ModuleTweakableAnimateGeneric' from assembly 'TweakableAnimateGeneric, Version=1.2.5263.29756, Culture=neutral, PublicKeyToken=null'.

(Filename: C:/BuildAgent/work/d3d49558e4d408f4/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 53)

Your Kethane, TweakableAnimateGeneric, TweakableLadders are not getting loaded for whatever reason. The recommendation is updating them or deleting them if you can't update. (They aren't working anyway.) This is probably not the problem, because...

MechJebRPM is getting both-loaded-and-not-loaded as I described about fifty posts above. (Blame Squad and their braindead plugin loader.) Either delete MechJebRPM.dll or make sure that the version of MechJeb that you have installed is the latest official release version, development versions do not work. This is a known problem which caused much argument in the past and everything will return to working once RPM 0.17 is released.

Deleting those two mods did the trick. Now to update them. Thanks for the help! :)

Link to comment
Share on other sites

Ok, after loading my mods onto a brand new KSP download and deleting them one at a time, I have discovered that if something alters the internal texture of a cockpit, and is then removed, the older textures stay, to an extent. Clearing ATM from my game caused the less wonky textures, and eliminating all of the other mods did nothing to fix this. If you had a similar issue as to what I had here -> http://forum.kerbalspaceprogram.com/threads/57603-0-23-5-RasterPropMonitor-make-your-IVA-a-glass-cockpit-%28v0-16%29-20-Apr?p=1193472#post1193472, you will have to download/extract a new version somewhere else, copy your mods over WITHOUT MOVING THE OLD SQUAD AND NASAMISSION folders, and your save folder to the new extract. Tedious and seemingly unnecessary, yes, but it worked.

Link to comment
Share on other sites

Ok, after loading my mods onto a brand new KSP download and deleting them one at a time, I have discovered that if something alters the internal texture of a cockpit, and is then removed, the older textures stay, to an extent. Clearing ATM from my game caused the less wonky textures, and eliminating all of the other mods did nothing to fix this.

Actually, cleaning out the Active Texture Management resized texture cache, which is located at GameData/ActiveTextureManagement/textureCache should be perfectly sufficient if the actual texture files have not been overwritten. (And if they were, nothing will help except restoring them from a backup.)

Link to comment
Share on other sites

Muahahahahahhaa.

OEWRRpQ.png

Why this is significant: sfr's own plugin for transparent internals was not involved. It's now a native RPM feature, and works better too. :) For example, you would see two portraits here even though you're controlling only one vessel.

For further details see http://forum.kerbalspaceprogram.com/threads/30803-WIP-FusTek-Station-Parts-Dev-Thread-%28continuation-of-fusty-s-original-work%29?p=1210683&viewfull=1#post1210683

Coming in version 0.17 once I track down the remaining issues, like why the kerbals don't spawn in vessels coming into range.

EDIT: Well, now they do. :)

Edited by Mihara
Link to comment
Share on other sites

So, how much mb of ram is this plugin eating, I have a suspicion it is slowing my game down big time (although this is complaining on a high level, since the plugin is so awesome, I shall NEVER deinstall it again)...

Cheers for making this mod, it is super-mega-uber-awesome, turning a game into a simulator

Link to comment
Share on other sites

So, how much mb of ram is this plugin eating, I have a suspicion it is slowing my game down big time (although this is complaining on a high level, since the plugin is so awesome, I shall NEVER deinstall it again)...

Not all that much actually, but it's nontrivial to say how much exactly. The biggest consumer of memory in KSP are model textures, which are never, ever getting unloaded from memory. RPM makes use of a bunch of textures, but most of them, like fonts, are very tiny, the exception being certain overlays like the bird on the navball, which are average in size. It creates no end of objects, but they don't consume all that much memory either, though they do consume CPU -- not as much as adding extra parts increases it due to physics, though. It creates textures for the screens, which are fairly big, but these reside directly in the GPU memory, and never actually make it back to the main memory until you do a screenshot. (Then they're copied back to main memory, saved as PNG, and get wiped out again.) In short, it's nothing compared to a large part pack.

Now, adding hundreds of actual controls, that can slow you down, but that's a matter of IVA design. :)

Link to comment
Share on other sites

What an amazing difference these displays make! I first saw them when playing with the KSO (it installs them automatically) but I wanted to do a proper install, and seem to have everything working well except for possibly mechjeb.

I'm sure this has been covered/answered/asked, but I'm not clear on the current version & state of things.

Do I still need the mechjeb part on the craft in order for the functions to appear on the displays? I've gotten the impression that it wasn't needed. I've wiped all mods and started from scratch, but I have to add the part in order for the autopilot functions to appear on the MFDs --which then also shows the MechJeb UI.

I have gotten ScanSat to work, so general mod interaction is there.

Link to comment
Share on other sites

Will this work with pods configured for the old SFR? If it will, it'll be awesome, and I'll be able to rid HOME of one plugin. :)

Link to comment
Share on other sites

Do I still need the mechjeb part on the craft in order for the functions to appear on the displays? I've gotten the impression that it wasn't needed. I've wiped all mods and started from scratch, but I have to add the part in order for the autopilot functions to appear on the MFDs --which then also shows the MechJeb UI.

Yes, you do need the actual MechJeb part -- or at the very least, the MechJeb PartModule, which you can add to your pod directly with a ModuleManager patch. RPM does not load MechJeb directly, it just connects to it if it is available.

Will this work with pods configured for the old SFR? If it will, it'll be awesome, and I'll be able to rid HOME of one plugin. :)

Depends on the texture they use for windows and certain properties of construction, in particular, whether the windows are properly one-directional meshes.

After enough mucking around with the concept I have determined that it is not currently possible to show transparent IVA (whether it is on the current vessel or on the neighbouring one) when the player is looking from inside an IVA. At least, not without introducing really annoying artifacts, i.e. kerbals floating around at odd angles. SFR's own hackish method of solving this problem (instead of correctly orienting the IVA when looking from inside, move it twenty meters to the left and hope the player can't see the floating kerbals) does not actually work well and prevents you from using more than one transparent pod per ship. (Not to mention that the whole reason I started on that was to fix this particular problem at sumghai's request -- stations are likely to involve more than one transparent pod per vessel.) The only practical solution is to have the windows be transparent while you're looking from outside the IVA, but go opaque once you go IVA. This requires certain things from pods:

  • IVA and the outer model should, obviously, match up strictly, which is apparently not the case for most pods. Though few of them, if any, were meant to be used as transparent, except those configured for SFR.
  • Windows must be a transform of their own, so that their transparency can be manipulated. (I suppose most pods fit this one, as they need this to apply specular shaders to windows.)
  • They must appear transparent (at least partially, or there's no point) with one shader and opaque with another shader. For example, they can have a texture with an alpha layer on the windows, and use KSP/Diffuse for opaque state while using KSP/Alpha/Translucent for transparent state. (The RPM module takes care of switching shaders as directed, and doesn't care which shader you pick, but the pair must satisfy this condition.)
  • They must remain transparent from the inside regardless of that state. I.e. pod exterior should be a mesh with normals pointed out only, and if any glass texture is desired from the inside, it should be a transparent texture on the internal model that can always be seen through.

Oh, by the way. Here's what happens when you try to do this to a stock pod:

Vhkh4hs.png

They all have bits of IVA sticking out of them. :)

Amusingly, SFR's own pod does not fit the criteria, because the windows end up non-transparent from the inside -- interior model has no mesh for windows, and the exterior model has a double-sided one. So when windows go opaque as the player goes into IVA, these windows also look opaque from the inside. :) This might be a problem with other pods configured for SFR plugin or it might not, but it's hard to tell right now.

Also, it looks like I need a new model for the example MFD prop, as the one that exists greatly confuses Unity when exposed to actual world-space by having broken colliders on it....

Edited by Mihara
typos, clarifications.
Link to comment
Share on other sites

So! Exciting times, I still have a few SFR based models I worked on back in August to finish... Any ideas when I can get to work on them? My pods look so empty :( I don't seem to be able to use SFRs plugin at all these days.

You can get the dev build and start right now? Dev build is linked on the first page of the wiki. I avoid publishing the link directly here because support requests. :)

Either way, RPM 0.17 is coming out before the end of the next week.

Link to comment
Share on other sites

First off, I want to thank you for the wonderful mod. Flying missions entirely from I.V.A. has almost made this into a whole new game. You mention in the RPM FAQ that if I wanted a variable displayed that was just derived from existing variables, to let you know. Semi-major axis is a really important number for orbital mechanics, maybe the most important. It is simply apoapsis + periapsis + twice the planetary radius / 2. Or the mean average of periapsis and apoapsis + planetary radius. Whatever makes most sense, I am not a math guy :). It's easy enough to figure out by hand but if it's not too much trouble, it would be great to have on hand.

Link to comment
Share on other sites

It is simply apoapsis + periapsis + twice the planetary radius / 2. Or the mean average of periapsis and apoapsis + planetary radius. Whatever makes most sense, I am not a math guy :). It's easy enough to figure out by hand but if it's not too much trouble, it would be great to have on hand.

Since KSP already knows that sort of thing about every orbit, I didn't actually need to compute it so it was trivial. SEMIMAJORAXIS, TARGETSEMIMAJORAXIS, please pick up the dev build (link is on the documentation wiki) and test. :)

Link to comment
Share on other sites

You can get the dev build and start right now? Dev build is linked on the first page of the wiki. I avoid publishing the link directly here because support requests. :)

Either way, RPM 0.17 is coming out before the end of the next week.

Glorious! Most glorious! :D

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...