Jump to content

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

Mihara

By Mihara
in KSP1 Mod Releases

 Share

Recommended Posts

DraggoonPlatoon

DraggoonPlatoon

Posted
Posted (edited)

So I found the output_log.txt I found this:

Non platform assembly: C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\ModuleManager.2.2.0.dll (this message is harmless)

Non platform assembly: C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\ModuleManager_1_5_7.dll (this message is harmless)

Non platform assembly: C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\JSI\RasterPropMonitor\Plugins\RasterPropMonitor.dll (this message is harmless)

Non platform assembly: C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\SCANsatRPM\SCANsatRPM.dll (this message is harmless)

AssemblyLoader: Exception loading 'SCANsatRPM': 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

I don't know what this means but it looks like the mentioned files didn't load properly?

EDIT: My game appears to be 32-bit, if that makes a difference

Edited by DraggoonPlatoon
Link to comment
Share on other sites
tofof

tofof

Posted
Posted

Mk1 cockpit lights:

A/D - ascent/descent, lights up red if you're going down and green if you're going up.

MECO - main engine cut off, lights up when the engine is off.

CONT - Contact light. Lights up when the lowest point of your ship (i.e. the landing gear) is 1.676m off the ground, which is what the length of Apollo LM's ground probes was. Once it lights up, you're supposed to shut the engine off and fall, in theory. :)

RCS and SAS toggle green/off matching the normal navball RCS/SAS indicators.

GEAR and LIGHT toggle green/off matching the normal altitude-display indicators.

STAGE is the staging lockout - green when the normal indicator is green, off when the normal indicator is purple.

(?) HEAT - obviously related to overheating but unsure of the lighting conditions.

(?) HIGHG - obviously related to g-meter but unsure of the lighting conditions.

(?) TWR is orange at a fractional (0.8, I assume all of 0.01-0.99) thrust-to-weight ratio. I assume it's green above 1.0 and off with no engine (or fuel?).

(?) FUEL - unlit at 40%, unsure of conditions.

The six unlabled lights to the right of the indicator lamps are:

[blue SAS] [Purple GEAR] [??]

[Orange RCS] [Yellow LIGHTS] [??]

These light in the named color when the associated lamp is lit.

Anyone want to fill in the missing pieces?

Link to comment
Share on other sites
Nukesnipe

Nukesnipe

Posted
Posted

So, I'm not sure why, but for the 0.24 releases, this mod will crash the game 100% of the time (I've tested it at least fifteen times by now.)

The game will boot up normally, it'll get to the main menu, and everything will run smoothly. At least, until I try to load up any of my saves, it'll freeze twice and then crash.

Link to comment
Share on other sites
Shively

Shively

Posted
Posted

Currently having the same issue as described by others - RPM's displays are static and greyed-out.

On KSP x64 with fairly extensive list of mods (can be provided if requested) - have Interstellar and RPM - issues with the two are noted, somehow I had them both running together (and functional) yesterday on a configuration that was causing crashes.. nuked offending mods after a reinstall earlier today, have the game running stably, but cannot get RPM displays functional. Here's my output_log: http://s000.tinyupload.com/index.php?file_id=30179993512079820398

Keeping a backup of current gamedata and going to try a fresh reinstall, see what I can work out, but that's about all I know to do off the top of my head. I'm nowhere near competent enough to make proper use of that log, anyways.

Link to comment
Share on other sites
Mihara

Mihara

Posted
  • Author
Posted
I'm having some weird gray screens on my moniters and I am unable to use them. I'm using 32-bit.

Broken Interstellar prevents correct loading.

I'd love to know how the hell that actually happens, but it's quite nontrivial to find out.

And same problem, but w\o buttons(((

https://www.dropbox.com/s/2ljgso8094kcf5v/KSP.txt

Broken installation, multiple patches in effect. Delete the entire JSI directory and reinstall.

Link to comment
Share on other sites
Mihara

Mihara

Posted
  • Author
Posted
How could I set the aviapfd as an overlay for a camera? let's say for a foreward pointing cam. Iv'e tried adding it as a backgroundhandler, but the background is black

Check the docs. https://github.com/Mihara/RasterPropMonitor/wiki/Background-handlers#jsiheadsupdisplay They're 80 pages long for a reason, and one of the reasons is that I didn't remember that this option existed myself. :P

You want the cameraTransform in JSIHeadsUpDisplay config, which will set a transform to be the camera in the usual way. You can't have more than source of a background (whether a handler or a simple camera) actually running on the same display -- they would occupy the same 'layer'. (You can define any number of them, but only the first one that loads will work and the rest will be ignored.)

Link to comment
Share on other sites
Themorris

Themorris

Posted
Posted (edited)

Thanks, I managed to do it.

I added the cam in to the backgroundhandler and below the hud

DoiOsyP.jpg


	PAGE
	{
		name = camExt1

		zoomFov = 10,30,5
		zoomButtons = 0,1
		text = Hyomoto/MFD/pages/overlayCam.txt
		//textureOverlayURL = Hyomoto/MFD/images/genericOverlay
		//textOverlay = Hyomoto/MFD/pages/menuOverlay.txt
		disableSwitchingTo = btn1, btn2, btn3, btn4, btn5, btn6, btn7, btn8, btn9, btn10, up, down, enter, escape, home
		BACKGROUNDHANDLER
		{
			name = JSIHeadsUpDisplay
			method = RenderHUD
			horizonTexture = JSI/RasterPropMonitor/Library/Components/HUD/ladder
			use360horizon = true
			horizonSize = 320,320
			horizonTextureSize = 480,480
			hudFov = 120
			headingBar = JSI/RasterPropMonitor/Library/Components/HUD/heading
			headingBarPosition = 160,123,320,37
			headingBarWidth = 320

			vertBar1Texture = JSI/RasterPropMonitor/Library/Components/HUD/rightscale
			vertBar1UseLog10 = true
			vertBar1Variable = RADARALTOCEAN
			vertBar1Position = 480,160,64,320
			vertBar1Limit = 0,10000
			vertBar1TextureLimit = 855,170
			vertBar1TextureSize = 640

			vertBar2Texture = JSI/RasterPropMonitor/Library/Components/HUD/leftscale
			vertBar2UseLog10 = true
			vertBar2Variable = VERTSPEED
			vertBar2Position = 96,160,64,320
			vertBar2Limit = -10000,10000
			vertBar2TextureLimit = 1845,208
			vertBar2TextureSize = 640


			cameraTransform = ExtCam1
			staticOverlay = JSI/RasterPropMonitor/Library/Components/HUD/hud-overlay
		}
		CONTEXTREDIRECT
		{
		  redirect = btn2,   camExt2
		  redirect = btn3,   camExt3
		  redirect = btn4,   camExt4
		  redirect = btn5,   camExt5
		  redirect = btn6,   camExt6
		  redirect = btn7,   camExt7
		  redirect = btn8,   camExt8
		  redirect = btn10,  camDock
		  redirect = escape, menuDefault
		  redirect = home,   menuDefault
		}
	}

I think that will be useful for flyring with a limited cockpit sight. Also you coud add a overlay for the docking alignment.

hOI9xKO.jpg

Edited by Themorris
Link to comment
Share on other sites
KingKolla

KingKolla

Posted
Posted

I use the 32-bit 0:24, when I try to install the mod the only result is the disappearance of the crew and the stage's sidebar; none of my creations (old and new) works ...

If I try to use a mod with RPM integrated the results are the same ....

I tried to re-download the game clear (without mod) but only with the RPM can not fly anything ...

I did not crash, of any kind ... any advice?

Ty all!

Link to comment
Share on other sites
Guamokolatokint

Guamokolatokint

Posted
Posted
That's exactly the wrong log file.

And I'm not sure three different versions of ModuleManager actually coexist well.

Hey! It's happy dll's family!

And i'm really fu'uped)))) It was a reason of all problems with monitors))))

Thx for telling))

Link to comment
Share on other sites
Mihara

Mihara

Posted
  • Author
Posted
Hey! It's happy dll's family!

And i'm really fu'uped)))) It was a reason of all problems with monitors))))

Thx for telling))

Technically, from at least as far as ModuleManager 1.5.0, it was written to support just this sort of situation -- multiple copies of DLL with different version numbers would have elections through a convoluted process, and only the one with the highest version number would actually run. However, I'm not sure if this actually works well in case when there's three of them, and I have a suspicion something got subtly broken in ModuleManager 2.2.0 that prevents this from working correctly.

Link to comment
Share on other sites
Mihara

Mihara

Posted
  • Author
Posted (edited)

Suddenly, realization dawns.

I know why a broken third party module can cause RPM to fail in grey-screens-no-error-message mode. I don't know whether I can do anything about it in terms of providing a sane error message, so I'm writing this down here for posterity, treat this as a lecture.

Unity has a behaviour-based object model. Objects of the game world share a more or less unified structure, and have so-called 'components' attached to them, which components are actually responsible for making objects behave in a specific way. This way, you can have an object that is "flying" and that is "a light source" and as long as behaviours don't fight each other, it's easy to combine the two to produce a "flying light source".

KSP extends this approach further by introducing PartModules and InternalModules, and RPM mostly provides InternalModules that make prop objects behave in certain ways. This involves extending Unity's own builtin behaviour lifecycle system -- Unity calls these behaviours at specific moments during the each game frame so that they may do the required magic.

What happens if somewhere, an unrecoverable error occurs? This produces a so-called "exception" -- execution of the function that tripped over the error stops, and it returns back with that error message, hoping that the function that called it will know what to do. The exception travels back up the chain of function calls, until it bumps into Unity, which writes an error message to the log and pretends nothing happened, for that is the way Unity likes things. (In many cases, especially obvious configuration errors, I would prefer it died and crashed to desktop -- I know which errors are recoverable and which aren't, and not that many are. But alas!)

But what if that error happens during behaviour startup, when the behaviour object is just settling into wherever it's going to live, gathering around data it needs to work? Well, that error will cause the Start() call to fail, and return up the execution chain until it bumps into Unity. I'm not sure if vanilla Unity will take notice of it and disable the behaviour -- more likely than not, it will call the same behaviour object during Update() so that it can do it's job, ready or not. That will probably cause a secondary error (some things that are needed for the work to happen did not happen) and a never ending spam of error messages.

If that were only Unity's behaviour objects, the only thing that would break would be this behaviour object itself, although that can be bad enough. But with KSP's PartModules and InternalModules, they're getting initialized by an intermediary -- which is itself a Unity behaviour, so it follows the same rules, and once one something-Module dies with an error, it doesn't intercept the error and passes it back upwards. If one breaks, all the objects that follow it in the initialization order will also break.

Remember the engines firing and RCS burning in the VAB? That's one manifestation of this effect -- one broken PartModule breaks the rest of the modules that live in this particular part, because it interrupted the chain of initialization.

Well, it happens with InternalModules too, but what breaks them isn't other InternalModules being broken (there's not that many of those floating around and I wrote most of them that aren't stock) -- it's broken ScenarioModules and other things that run without being attached to a Part. When they die, RPM screens never even get to start initializing, because the error interrupted the entire initialization cycle for everything, and they never get to show the error message either, because they can't run in the first place.

Edited by Mihara
clarification
Link to comment
Share on other sites
DraggoonPlatoon

DraggoonPlatoon

Posted
Posted (edited)

So are you suggesting that we should only have one Module Manager file? And not 2.2.0?

EDIT: I FIGURED IT OUT! I had multiple MM files from different mods that were clashing with each other, so I removed all but MM 2.2.0 and it works perfectly. So in other words as Mihara said: ONLY USE ONE MM VERSION FILE.

Edited by DraggoonPlatoon
Link to comment
Share on other sites
SmarterThanMe

SmarterThanMe

Posted
Posted

I have found over the last couple of gaming sessions that I now flat out can not land without being IVA and having the right screens open. Thanks RPM. :P:)

Separate question. Would it ever be possible to drop a camera somewhere and then be able to hook into it's view of something? For example, having a camera in a spent stage following the path of your rocket and such.

Link to comment
Share on other sites
DesTroy

DesTroy

Posted
Posted

I registered just to relay this information:

The glitch where the HUD and ADI overlays become super dark is caused by OpenGL rendering.

This is why it occurs on Linux and Mac.

I am using Windows 7, and was using the 64-bit version to allow for all my mods. The HUD and ADI was fine during this time.

The instability, glitches, and enormous memory usage caused me to switch the the 'amazing' openGL switch.

I can run all my mods with only a 2.6 GB RAM footprint in 32-bit KSP with the -force-opengl command parameter.

However, this is when they problem occurred with the super dark overlay. I have confirmed this by running the game with no OpenGL switch with the exact same install, and they magically work again with the default DirectX (I have not tried DX11 though).

As to why this occurs I have no idea whatsoever.

Also:

It may be unrelated or not causing the problem, but I also noticed that the files that ARE the ones that become dark have a Y dimension size of 2044 pixels (Instead of say 2048, as in some of the other image files) Could this be the problem? Maybe OpenGL freaks out when an image isn't a power of 2 size? Can you do a check by reworking ladder.png to be a power of 2?

Link to comment
Share on other sites
SpaceSmith

SpaceSmith

Posted
Posted

Okay, so I have had the problem of getting RPM to work correctly, and with Spaceplaneplus (Which I have seen pictures of it working properly with) and KSI MFD (Which I have asked in that thread for help)

I am using KSP .24 x64 and the problems I am having are that the buttons at the top of the MFD of RPM are greyed out instead of A-E... and with Spaceplane Plus it only has 1 MFD, instead of the multiple I have seen. And KSI MFD won't work at all with RPM.. Here is the output_log.txt from KSPx64_Data. As well as 2 screenshots of the inside of the spaceplane plus. I have also tried with just RPM installed and the same problem persists of the buttons not being correct, or KSI MFD not working on top of it.

https://www.dropbox.com/s/eq3lp3daobzknmy/output_log.txt

https://www.dropbox.com/s/1x76miszi0mhear/screenshot2.png

https://www.dropbox.com/s/j3tjqeqnb7e1rfb/screenshot3.png

Any ideas?? :S

Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...