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

[DasBananenbrot]

[*]The JSITransparentPod module will clean your pod windows just like the infamous sfr's plugin would. The drawback is that you can't see any internals within transparent pods if you are IVA. I'm not sure this KSP limitation is possible to work around -- the challenge isn't that you can't see them, the challenge is that you would see double. Warning, this is still highly experimental because I keep finding new things wrong with it.

Does that really mean when the transparentpod is used you don't see any of the internals while in IVA view? Sounds like a major drawback since improving IVA is what this is mostly about.... *Confused*

[Mihara]

Does that really mean when the transparentpod is used you don't see any of the internals while in IVA view? Sounds like a major drawback since improving IVA is what this is mostly about.... *Confused*

You don't see any internals except those in your own pod, of course.

[DasBananenbrot]

You don't see any internals except those in your own pod, of course.

Ah okay, I was slightly confused there

[Nhawks17]

No, nothing fatal should happen to your save file even if you delete RPM entirely, the only exception would be if you used the provided external camera part in that save (and deleted it, that is. It's been moved between 0.16 and 0.17, but the name and everything else didn't change.). Which sucks, so very few people use it.

Ahh ok cool, thanks for the help

[shaw]

Mihara, there's a bug in 0.16-0.17-upgrade-patch.cfg. It only replaces the first MFD in file. According to ModuleManager Wiki you should add ",*" to replace all props:

@INTERNAL[*]:Final
{
    @PROP,*[RasterPropMonitorExampleMFD]
    {
        @name = RasterPropMonitorBasicMFD
    }
}

but beware; I haven't tested this yet!

[Mihara]

Mihara, there's a bug in 0.16-0.17-upgrade-patch.cfg. It only replaces the first MFD in file. According to ModuleManager Wiki you should add ",*" to replace all props:

@INTERNAL[*]:Final
{
    @PROP,*[RasterPropMonitorExampleMFD]
    {
        @name = RasterPropMonitorBasicMFD
    }
}

but beware; I haven't tested this yet!

Oops? Regardless, the comment says the IVAs relying on it need to be updated.

[Capt. Hunt]

Hey, I just updated to the latest version of the KSO pack, and now whenever I use one of his IVAs I get an error message that says "RasterPropMonitor Initialization Error: Check your Configs." I tried updating to the newest version of RPM, and I tried rolling back to the previous KSO build, but I still get the message, any ideas what the problem is? And what configs do I need to check?

[Mihara]

Hey, I just updated to the latest version of the KSO pack, and now whenever I use one of his IVAs I get an error message that says "RasterPropMonitor Initialization Error: Check your Configs." I tried updating to the newest version of RPM, and I tried rolling back to the previous KSO build, but I still get the message, any ideas what the problem is? And what configs do I need to check?

First, you need to post your KSP_Data/output_log.txt which contains the actual details of what's going on.

But my guess is that you tried updating by overwriting files. Which in case of a 0.16->0.17 update will result in two copies of MechJebRPM and other untold horrors.

[mythic_fci]

If possible, could you please upload this to the new community mod repository (Kerbal Stuff)? Just asking

[Mihara]

If possible, could you please upload this to the new community mod repository (Kerbal Stuff)? Just asking

I'd be happy with using GitHub only and I've been ignoring Spaceport when it existed because it sucked too much. Just saying. I don't see whom this would help (who in the world can't access both Curse and GitHub?) and I don't like maintaining and updating three separate download locations, two are enough of a handful.

You can do it if you like, GPLv3 for the code and CC for the data permit anyone to do it. But then when you decide to go away from KSP and it goes stale, that's going to be your bad karma.

[sumghai]

I'd be happy with using GitHub only and I've been ignoring Spaceport when it existed because it sucked too much. Just saying. I don't see whom this would help (who in the world can't access both Curse and GitHub?) and I don't like maintaining and updating three separate download locations, two are enough of a handful.

You can do it if you like, GPLv3 for the code and CC for the data permit anyone to do it. But then when you decide to go away from KSP and it goes stale, that's going to be your bad karma.

I concur wholeheartedly with Mihara on this one.

Add-on authors have enough work as it is maintaining their current releases, working on new features / fixes for upcoming releases, handling user support requests that sometimes turns out to be cases of PEBKAC - I too don't fancy spending more time setting up yet another distribution channel and keeping documentation up-to-date there.

I do have a Kerbal Stuff account for in case I change my mind, but in the near future it's unlikely I'll mirror my add-ons there, either.

[mythic_fci]

I concur wholeheartedly with Mihara on this one.

Add-on authors have enough work as it is maintaining their current releases, working on new features / fixes for upcoming releases, handling user support requests that sometimes turns out to be cases of PEBKAC - I too don't fancy spending more time setting up yet another distribution channel and keeping documentation up-to-date there.

I know... Just asking.

I'd be happy with using GitHub only and I've been ignoring Spaceport when it existed because it sucked too much. Just saying. I don't see whom this would help (who in the world can't access both Curse and GitHub?) and I don't like maintaining and updating three separate download locations, two are enough of a handful.

As I said, just asking. If you would like, I'll help you maintain a Kerbal Stuff DL link if required. I'll update the mod if required.

Edited June 29, 2014 by FCISuperGuy

[BudgetHedgehog]

What does that mean?

He's saying having to maintain 3 separate download locations isn't something he's interested in. Curse and GitHib work fine because everyone in the world can reach it (probably), what's the point in him uploading it to Kerbal Stuff?

And you don't need permission - the license ("GPLv3 for the code and CC for the data") doesn't require it.

[Mihara]

To elaborate.

Somehow, when Spaceport was broken for the umpteenth time, for years, nobody stepped up and started advertising their own mod repository, but now that Curse is in the mix, there just has to be an alternative. What's wrong about Curse? Sure, the name's lousy, who cares.

My mods stay on GitHub as the primary distribution channel, because that is how they are developed, and because there's no likelihood that they're ever going to become unsuitable for GitHub, (It's open source? GitHub will host it for sure, as long as it gets to host the source. No questions asked. No bandwidth caps, no ads, no nothing.) nor there is a likelihood GitHub will become inaccessible for most of the Net. (Much of the net will just break down if this happens, because many a web service pulls it's web applications direct from GitHub, so we'll have bigger problems.) I started posting them on Curse as well, because that's where most players who do not read the forums will go to look for them first, seeing as how it's the officially blessed mod repository now. Even that is an extra step for me not to forget when preparing a release, and I don't have a very good track record of keeping all of those. Kerbal Stuff is neither the "officially blessed" repository, nor "a place where most people who don't read the forums will go to look for mods" and therefore I'm not interested in posting my mods there.

If you want RPM to be there -- or anywhere else, for that matter! -- anyway, do whatever, the licenses permit you to do so. Keeping a link to the source on GitHub is the only true requirement until you start modifying the source. Just make sure people know whom to call when the download you maintain is out of date.

[Mecripp]

Hey, I just updated to the latest version of the KSO pack, and now whenever I use one of his IVAs I get an error message that says "RasterPropMonitor Initialization Error: Check your Configs." I tried updating to the newest version of RPM, and I tried rolling back to the previous KSO build, but I still get the message, any ideas what the problem is? And what configs do I need to check?

If you editted the 0.16-0.17-upgrade-patch.cfg to match what Shaw post here http://forum.kerbalspaceprogram.com/threads/57603-0-23-5-RasterPropMonitor-make-your-IVA-a-glass-cockpit-%28v0-17%29-27-Jun?p=1237036&viewfull=1#post1237036 thats why your getting the error just leave it as Mihara had it and it works just fine.

[Mihara]

If you editted the 0.16-0.17-upgrade-patch.cfg to match what Shaw post here http://forum.kerbalspaceprogram.com/threads/57603-0-23-5-RasterPropMonitor-make-your-IVA-a-glass-cockpit-%28v0-17%29-27-Jun?p=1237036&viewfull=1#post1237036 thats why your getting the error just leave it as Mihara had it and it works just fine.

Actually, this patch should not affect KSO at all, since all their MFDs were customized and did not contain references to RPM texture or model locations, which was most of what got changed.

[Mecripp]

Actually, this patch should not affect KSO at all, since all their MFDs were customized and did not contain references to RPM texture or model locations, which was most of what got changed.

The KSO as a RPM display on a window if you edit your patch to match what Shaw posted you get a error message and the display on the window shows a whole prop monitor on the window and your patch for MOARdV FASA display didnt work .

EDIT- Not sure what you would call it when they just display what a prop would just on the window or glass that hide the outer edge of the prop and buttons your patch works with it and Shaw

Shows the outer edge and buttons on glass or window, Hope that sounds better.

EDIT- we talk about FASA now or KSO ? lol I'm lost which 1 works ? KSO if patch is edit to look like

@INTERNAL[*]:Final

{

@PROP,*[RasterPropMonitorExampleMFD]

{

@name = RasterPropMonitorBasicMFD

}

}

I got a error and the monitor on the window was wrong. Edited June 29, 2014 by Mecripp2

[Mihara]

The KSO as a RPM display on a window if you edit your patch to match what Shaw posted you get a error message and the display on the window shows a whole prop monitor on the window and your patch for MOARdV FASA display didnt work .

Gweh... Okay, give me a moment to install FASA and actually test it.

EDIT: No, I'm pretty sure it actually works. The buttons are in different locations on the new model though, which is why it needs more work, but yes it loads, and I get no error messages.

Edited June 29, 2014 by Mihara

[Capt. Hunt]

I haven't edited anything to do with RPM or the KSO personally, but it's possible that something was changed by the KSO scripts.

here's the output log file:

https://dl.dropboxusercontent.com/u/18212815/output_log.txt

I'll try reinstalling the KSO and RPM again and see if that helps.

[Mecripp]

When you installed RPM .17 you did delete the JSI folder in ksp/gamedata and install the new 1 ?

[TheReaper]

rpm .17 screwed my ivas... so thanks can i get rpm 16 back please? kso no longer has ADI PFD switches in one button, spaceplane plus iva screens no longer working, stock parts iva screens doesnt have classic lay out of A B C D 1 2 3 4 instead series of buttons all marked with a white square that says nothing, i want the menu back..

[Mihara]

rpm .17 screwed my ivas... so thanks can i get rpm 16 back please?

I did warn you not to hurry to install this one. I did warn every IVA author I could track down that was using RPM, most of them a couple weeks ago.

And I did change the download link to point to the page with all releases, not just the latest.

[Mihara]

I'll try reinstalling the KSO and RPM again and see if that helps.

Do reinstall things correctly:

MechJeb moduleRegistry creation threw an exception in LoadComputerModules loading SCANsatRPM, Version=0.16.5223.32097, Culture=neutral, PublicKeyToken=null: System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded.

AssemblyLoader: Assembly 'MechJebRPM' has not met dependency 'RasterPropMonitor' V0.17

AssemblyLoader: Assembly 'MechJebRPM' has not met dependency 'MechJeb2' V2.2

SCANsatRPM from version 0.16. MechJebRPM from version 0.17. The main DLL is version 0.16. MechJeb not dev build 254 or later.

Squad did not give me an option to package my entire mod into a single file that could only go into one location, even though I wish dearly they would, because it would save me from support requests like these.

Maybe I should package the mod into RAR, at least that forces people to think about how to unpack it, and they can't just drag and drop folders and pretend everything's okay.

[TheReaper]

I did warn you not to hurry to install this one. I did warn every IVA author I could track down that was using RPM, most of them a couple weeks ago.

And I did change the download link to point to the page with all releases, not just the latest.

i got back to 16, everything works fine, i recall not overwriting unto the previous version ,did not come here to cry its not working without doing clean re installs 5 times, dont even have mechjeb or scanset, just their plugins are forced to me,

allthough out of my curiosity, people can be a bit d**k to people who fail and cause problems then whine about it because they acted a bit idionicly, but why do that to (exaggerating this) "customers"

[Mihara]

i got back to 16, everything works fine, i recall not overwriting unto the previous version ,did not come here to cry its not working without doing clean re installs 5 times, dont even have mechjeb or scanset, just their plugins are forced to me,

allthough out of my curiosity, people can be a bit d**k to people who fail and cause problems then whine about it because they acted a bit idionicly, but why do that to (exaggerating this) "customers"

...I am generally hostile to people who can't read. I can't help it, it's professional and too far deeply ingrained to get rid of by now -- teaching in a university makes you loathe people who reach you without actually being able to read. For the simple reason that the only practical teaching method available to you in this situation is discussing things they have read with them.

In this particular case, you appear to have interpreted a response to a specific complaint citing logs by one "Capt. Hunt" as referring to you. Unless you are somehow one and the same person, I have to ask you a question...

...Can you read?

As for forcing plugins on you, that's another story... If you do not have MechJeb or SCANsat, SCANsatRPM.dll and MechJebRPM.dll can be safely deleted. Normally, if you do not have the plugins those shims were meant to interface to, they remain inert and RPM gracefully degrades. That is, up until version 0.23, when this changed and the notion of plugin-that-is-both-in-memory-and-not-in-memory came up and started wrecking things.

In an ideal world, I would be able to actually detect if a specific plugin is present and run or not run code from it. But Squad did not give me this option either. Instead, they introduced the notion of KSPAssembly/KSPAssemblyDependency, which would fix more or less all cases of plugin dependency, if it were widely supported.

Then they did nothing to document it and tell us to use it.