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

[Coga19000]

Well, the 0.90 compile doesn't work for me. All it does is show me the monitors completely blank -completely, as in they are totally white, frame and buttons too. What is wrong??

[MOARdV]

Well, the 0.90 compile doesn't work for me. All it does is show me the monitors completely blank -completely, as in they are totally white, frame and buttons too. What is wrong??

Something is wrong, clearly. But I don't have enough info to go on. When you say "0.90 compile", are you using the one that was on DropBox, or did you get the full 0.19 dev package from GitHub? If the whole things is white (frame and buttons), it sounds like RPM was installed to the wrong location. But, again, need more info.

[karamazovnew]

I'm guessing most are playing with SETI now (if not, they should). But in career mode, the RPM bugged out and started flooding my log as soon as I enabled SETI. Looking in the cfg files, I found this in the SETI-Settings.cfg file.

//------\\

//---RemoteTech---\\

//------\\

//No signal delay

//old remote tech settings

@EnableSignalDelay = False

//new remote tech settings

@RemoteTechSettings

{

@EnableSignalDelay = False

}

There is something strange about those line, and I DO use signal delay, so almost by accident I decided to comment those line out. Next play, RPM was working flawlessly. No idea why

[Coga19000]

Something is wrong, clearly. But I don't have enough info to go on. When you say "0.90 compile", are you using the one that was on DropBox, or did you get the full 0.19 dev package from GitHub? If the whole things is white (frame and buttons), it sounds like RPM was installed to the wrong location. But, again, need more info.

The GitHub version, linked from the OP. And yes, it does advise me to check the installation. But I installed it exactly as I did at 0.25 - simply pasted JSI into GameData folder. I did use another ModuleManager at he beginning, though 0already had the latest ersion - but even after I replaced it with the one provided, it didn't work.

[Fr8monkey]

OK. Looked through pages; and didn't see what I am doing wrong. All I am getting is a ghostly looking images on the screens. also none of the buttons work. I loaded as suggested and no help.

Any help would be helpful.

[Gaalidas]

So, from the looks of it, my attempt at recompiling RPM with my little addition that I wrote about a while back was a fail. The effect that I was going for was a success, in fact it was a pretty good success... but in the process it seems that half of the functions in reference to certain buttons and such get broken and produce exceptions in the log when the DLL is processed. This doesn't happen with your compiles. So yeah... I can't do it right apparently.

[MOARdV]

So, from the looks of it, my attempt at recompiling RPM with my little addition that I wrote about a while back was a fail. The effect that I was going for was a success, in fact it was a pretty good success... but in the process it seems that half of the functions in reference to certain buttons and such get broken and produce exceptions in the log when the DLL is processed. This doesn't happen with your compiles. So yeah... I can't do it right apparently.

I use Visual Studio Express 2013 for code builds. I can give you some pointers for configuring it if you're not familiar with setting it up for KSP builds.

[Gaalidas]

SharpDevelop has a lot in common with Visual Studio, and so far (at least as far as most of the recompiles I've done for experimental stuff) it has proved to be sufficient. I used the project files received with the source, just had to redirect the references to their local paths. It is, however, quite possible that there's a reference or targeted framework mismatch somewhere. I'm still too new at this to even know what the heck I'm saying right now.

As an experiment, I have temporarily extracted the code used to make the transparent pod work and created a new project in which I referenced the RPM plugin and I'm going to see if I can get just that code to work right with the precompiled build from the download. That will, at least, tell me if I'm totally unable to build for KSP or not. I suspect this will work though, as long as I wrote my MM patch properly, considering I've collaborated on the Kerbal Foundries project and successfully compiled and run several builds before.

Really frustrating though.

UPDATE: And... success. So, I can compile new mods for KSP without issues, it's just something about the rest of the RPM mod that is acting screwy for me.

So, a little update on what I did with the original code just in case you decide to roll it in to a real update.

Under the KSPField definitions I added a new field:

[KSPField]
public bool disableInEditor;

And then I added this to the "public override void OnStart(StartState state)" function:

if (HighLogic.LoadedSceneIsEditor && Equals(disableInEditor, true))
                return;

which basically just skips the rest of the transparent pod code if you're in the editor AND the "disableInEditor" bool comes out as true. It defaults to false. In this way, the author of the pod (or the user along with an MM patch or a cfg edit) can choose whether or not editor performance is an issue. I've found that cockpits with simpler setups and a single window transform operate with very few issues, but pods that have several window transforms and a lot of props that have RPM functionality in them (such as the ASET ERS rover) make editing a real chore. To edit all the pods I have installed with the new parameter, I simply made an MM patch that searched for all the pods with that module in them and added the "disableInEditor = true" line to them. No failed functionality on the rest of the pod so far as I can see.

Edited February 27, 2015 by Gaalidas

[MartGonzo]

Is anyone having trouble getting this to work with the spaceplane Mk2 cockpit?

it used to work fine but when I rebuilt my ksp recently it stopped working and I can't figure out why, it works ok with the mk1 pod but the screens in the mk2 are the default ones.

I tried the 0.19 dev version and the older one on curse

any thoughts or suggestions gratefully received.

[Gaalidas]

Here's a few things you should be aware of:

- As stated before, OpenGL mode breaks the hud, it's there, but it's black. DirectX11 mode works well.

Are you quite sure about this little factoid? I run in OpenGL mode quite regularly and have had absolutely no trouble with the screens.

[Tarheel1999]

Is anyone having trouble getting this to work with the spaceplane Mk2 cockpit?

it used to work fine but when I rebuilt my ksp recently it stopped working and I can't figure out why, it works ok with the mk1 pod but the screens in the mk2 are the default ones.

I tried the 0.19 dev version and the older one on curse

any thoughts or suggestions gratefully received.

You need nil2work's spp patch. It's the last link in his sig. http://forum.kerbalspaceprogram.com/threads/84054-v0-90-v-25-Transparent-Pods-v1-2-2-for-KSP-v0-90?p=1230915&viewfull=1#post1230915

[MartGonzo]

You need nil2work's spp patch. It's the last link in his sig. http://forum.kerbalspaceprogram.com/threads/84054-v0-90-v-25-Transparent-Pods-v1-2-2-for-KSP-v0-90?p=1230915&viewfull=1#post1230915

Many thanks Tarheel1999

You're a lifesaver!

[MOARdV]

Are you quite sure about this little factoid? I run in OpenGL mode quite regularly and have had absolutely no trouble with the screens.

@Gaalidas - you are on a PC, right? I assume Mac and Linux both work in OpenGL mode, since that's the only option on those two.

I have tried to run in OpenGL mode, but I can not get KSP to work correctly with -force-opengl. When I run it with that flag, I have a black rectangle in the lower-left corner during the loading screen, and in the game screens, most of the screen is dark / solid colored, with only the lower-left corner showing anything. It's kind-of hard to navigate with 3/4 of the screen not visible. I tried -popupwindow (I think it is), and that didn't fix it, either, so for now the OpenGL bug is in limbo.

[Gaalidas]

That is really weird, because I run in OpenGL mode and while the initial loading does have a few glitches (it's open, but shows my desktop instead for a few minutes before opening properly) it eventually fixes itself and runs perfectly, even on the RPM screens.

UPDATE: And yes, to answer your question, I'm on a PC. a non-gaming laptop too, so that means sub-standard integrated graphics.

[jackellice]

I have that black rectangle when my game loads up. and that bit becomes the only bit visible after the game loads. After i alt tab out and back in it's perfectly fine. I didn't realise it was an openGL issue. Eitherwise, RPM works fine with mine as well as Hymoto's MFD, though I admit not without a few changes.

[Fly Angry]

I've a question about the emissive texture for the buttons on the included MFD40x20 prop.

Is this something that's switched on / off somewhere via menu option or something? I was experimenting with an internal space I'm modding and noticed the emissive texture listed in the MODEL{} section of the MFDs prop .cfg, but it's definitely not working on my end.

Thoughts?

[Wavechaser]

Yes, I heard you the first time. I appreciate your desire to have this conflict resolved, but please understand that maintaining RPM is a hobby of mine. It is something I do in my scant free time. Since I don't use Procedural Parts, nor any of the other mods you've listed as potential conflicts, I am not in a position right now of characterizing the problem. When I have time to download these mods, try them out, and test for compatibility, I will do so, but it's not happening today, nor any time in the immediate future. I'm sorry if that is a problem, but since this mod doesn't pay my bills, it's not on the top of my priority list.

Alright, gotcha.

[optimusjamie]

Is there an RPM config for the SP+ parts?

[BudgetHedgehog]

Is there an RPM config for the SP+ parts?

7 posts up, mate ^

You need nil2work's spp patch. It's the last link in his sig. http://forum.kerbalspaceprogram.com/threads/84054-v0-90-v-25-Transparent-Pods-v1-2-2-for-KSP-v0-90?p=1230915&viewfull=1#post1230915

[ATG]

Is it possible to config a prop button to function like the SAS buttons by the nav ball (follow prograde, retrograde, etc.) ? Does RPM need to be updated to do this or can it be done in its present state?

I saw some examples that use the mechjeb plugin for this functionality...now that it is a stock feature, it would be cool to implement this for those like myself that don't use mechjeb.

[MOARdV]

Is it possible to config a prop button to function like the SAS buttons by the nav ball (follow prograde, retrograde, etc.) ? Does RPM need to be updated to do this or can it be done in its present state?

I saw some examples that use the mechjeb plugin for this functionality...now that it is a stock feature, it would be cool to implement this for those like myself that don't use mechjeb.

The dev build of RPM 0.19 supports the SAS modes, but I doubt if it's used anywhere other than the cockpit I use for testing things.

[ATG]

Hi MOARdV...thanks for keeping RPM updated in Mihara's absence.

After reading through the wiki and looking at some examples I was able to make the switch work. When the button is pushed on, the SAS control modes work as intended....problem is once the button is pushed on, the button remains stuck in the on position. I have to turn it off via the default sas mode buttons and then the custom button will reset to the off position. Any idea what I am doing wrong?

Here is the button's cfg file:

PROP

{

name = ATG_AP_SASPrograde

MODULE

{

name = JSIActionGroupSwitch

animationName = SwitchLightAnim

switchTransform = SwitchPUSHcollider

actionName = plugin

PLUGINACTION

{

name = JSIInternalRPMButtons

actionMethod = ButtonSASModePrograde

stateMethod = ButtonSASModeProgradeState

}

}

MODULE

{

name = JSIPropTextureShift

transformToShift = SwitchNamePlate

layerToShift = _MainTex _Emissive

x = 0.25

y = 0.75

}

}

proxy = 0, 0, 0, 0.035, 0.015, 0.03, 1, 0, 0

[RealTimeShepherd]

@MOARdV

Hi, I'm trying to use RPM and some ALCOR props to mock up an Orion style control panel

This is my WIP effort so far

Because it is going to involve a lot of switches, I want to utilise Action Groups Extended

So, in the cfg file for each prop, I can currently use action = custom01 to custom10 for the first ten action groups, but if I go beyond that to the additional action groups from AGX, then it just disables the prop. Is there any way around this?

Kind Regards!

RealTimeShep

[MOARdV]

After reading through the wiki and looking at some examples I was able to make the switch work. When the button is pushed on, the SAS control modes work as intended....problem is once the button is pushed on, the button remains stuck in the on position. I have to turn it off via the default sas mode buttons and then the custom button will reset to the off position. Any idea what I am doing wrong?

You are doing nothing wrong - the behavior is by design. The mode buttons control which mode SAS is in, not whether SAS is turned on or off (this behavior is different than the MechJeb autopilot buttons). Pressing the button in your example tells SAS that you want it to hold prograde when it's switched on, but it does not actually switch SAS on, since there is a separate action group control to enable/disable SAS (using "actionName = sas"). To use the SAS mode buttons, you will need a group of them to control the modes, plus a master "On/Off" switch, kind of like this:

In this instance, SAS is configured for Stability Assist, and it's off (the top SAS indicator is yellow for off, green for on).

If you think this is confusing, I would be willing to change it so that the buttons turn SAS on/off and set the mode, which eliminates the need for a separate SAS button, but it makes it harder to know which SAS mode is going to be selected if you use the generic SAS switch.

So, in the cfg file for each prop, I can currently use action = custom01 to custom10 for the first ten action groups, but if I go beyond that to the additional action groups from AGX, then it just disables the prop. Is there any way around this?

Short answer, no. Longer answer, I would have to introduce a hard dependency on AGX to support additional custom actions using the custom## format, which would force people to install AGX to use RPM. It is probably possible to create a "AGXRPM.dll", similar to the MechJebRPM.dll, that would make it possible to use those additional action groups, but I don't have time to for that.

[ATG]

Thanks for the explanation, now I understand how it works. I was able to make all of the buttons work properly now. I appreciate the offer to change it, however I think the way you currently have it implemented makes sense and works best.

Thanks again.