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

[DaMichel]

Disclaimer: I totally like this mod and i would like to use it more. But i have problems with the readability of the MFDs and the HUD is particularily bad.

The texture interpolation seems to use nearest neighbor or so. Looks really bad. And not only that, when i zoom in, the text appears to have a double border around it: text is green, then black border, then green border. Any idea? I don't think this is normal ... and it has been like this for me since ever.

See, in Black Shark for instance readability is much better for everything. You only have to zoom in when you want to see details on the map or the tv screen.

Apologies for complaining ... i tend to post mostly when something bugs me

[Mihara]

Disclaimer: I totally like this mod and i would like to use it more. But i have problems with the readability of the MFDs and the HUD is particularily bad.

The texture interpolation seems to use nearest neighbor or so. Looks really bad. And not only that, when i zoom in, the text appears to have a double border around it: text is green, then black border, then green border. Any idea? I don't think this is normal ... and it has been like this for me since ever.

There is next to nothing I can do regarding interpolation, I'm afraid. Enforcing texture interpolation in your graphics driver settings for KSP might help, but that's about it.

Speaking of the font, though, the HUD font does actually have a black border. You can find it in JSI/RasterPropMonitor/Libary/Fonts/hudfont.png -- and you should have no problems editing it with, say, Paint.NET to produce something more readable. In fact, I could use it in the next version, if you do manage to produce something better than what currently exists.

[DaMichel]

Hm right. I tried to enable trilinear interpolation with mip mapping on the RenderTexture, but no luck. Cannot get it to work.

The extra green border around HUD text must be an alpha blending issue. The texture generated by taking screenshots is okay.

[nli2work]

The HUD PNGs are rather blurry to begin with. I found editing those PNGs helps with readability for HUDRenderer elements. the displayed text defined in the HUD page is determined by the overall font for the whole prop, you need to create your own set of bitmap font to make that more readable.

[DaMichel]

Yeah. I edited the font textures now. I removed the borders and i even blurred the non-hud texture to imitate mip map filtering. It looks okay-ish for a workaround and helps against aliasing artifacts.

[Vespene]

The borderless font is a marked improvement.

I don't really mind nearest neighbor for it gives the panels an old school pixely look.

[Mihara]

The borderless font is a marked improvement.

I don't really mind nearest neighbor for it gives the panels an old school pixely look.

Technically, it doesn't have to be. Monitor pixel sizes can be arbitrarily large, and since they're RenderTextures, they live in the GPU memory -- this would stop them from looking like they're nearest neighbour interpolated. Fonts could be bigger as well. But I'm afraid that with the amount of monitors in a typical RPM pod, this will start causing performance problems, because not everybody has gigabytes of GPU RAM, and nothing else in KSP requires that much of it.

[K3-Chris]

1. refreshRate should be outside the VARIABLESET block. Not that this would cause an initialization error...
   
2. Are you sure such a transform actually exists and has an attached renderer?
   
3. For that matter, you have "threshold" in there, which would not make emissive slide across the gauge, it would flip it between states if you have less than 10% fuel remaining.
   
4. Seeing the log would be helpful, because the actual reason for init failure is logged.
   

Thanks for the help, sorted it out and it's working swimmingly:

Javascript is disabled. View full album

Sorry to bother you with another question:

https://github.com/Mihara/RasterPropMonitor/wiki/Prop-modules#rotation-mode

Mentions rotating transforms, but it's tied to variables etc as you'd assume for use with dials and such, is it possible to use it to just turn a transform say 90 degrees? I'm making this prop:

(leftmost dial is the only one I've modified the texture of so far, they're all going to be)

And I want 2 variants, that horizontal orientation, and one vertical, I basically just need to turn the 3 dials 90 degrees between the versions, I can save both as their own .mu but props doesn't support MODEL so I'd need 2 folders and 2 sets of all the textures etc, seems wasteful if I can just turn the transforms

[Olympic1]

Thanks for the help, sorted it out and it's working swimmingly:

http://imgur.com/a/0Owmg

Sorry to bother you with another question:

https://github.com/Mihara/RasterPropMonitor/wiki/Prop-modules#rotation-mode

Mentions rotating transforms, but it's tied to variables etc as you'd assume for use with dials and such, is it possible to use it to just turn a transform say 90 degrees? I'm making this prop:

http://i.imgur.com/EaQUG87.png

(leftmost dial is the only one I've modified the texture of so far, they're all going to be)

And I want 2 variants, that horizontal orientation, and one vertical, I basically just need to turn the 3 dials 90 degrees between the versions, I can save both as their own .mu but props doesn't support MODEL so I'd need 2 folders and 2 sets of all the textures etc, seems wasteful if I can just turn the transforms

nice feature

[Mihara]

And I want 2 variants, that horizontal orientation, and one vertical, I basically just need to turn the 3 dials 90 degrees between the versions, I can save both as their own .mu but props doesn't support MODEL so I'd need 2 folders and 2 sets of all the textures etc, seems wasteful if I can just turn the transforms

Props does support MODEL {}. My props use it all the time, since I don't make models.

PROP
{
	name = JSIActionGroupLabelButton01
	MODEL
	{
		model = Squad/Props/ledPanelSpeed/model
	}
        ....
}

There is currently no provision in RPM to turn something once on startup, although you can use a number in place of variable in VariableAnimator (Any of the three elements of the scale -- top, bottom and the "needle" -- can be either any RPM numeric variable or a straight number, so you can drive the ends of the scale around a static number if you want, or have all three as static numbers) and it will turn, it'll just be wasteful. For an example of turning things, see JSI/RasterPropMonitor/Library/Props/SimpleProps/TrimmerKnobs.cfg -- these are stock knob models. If you replace variableName with a number, it will turn once and stop.

[K3-Chris]

Props does support MODEL {}. My props use it all the time, since I don't make models.

PROP
{
	name = JSIActionGroupLabelButton01
	MODEL
	{
		model = Squad/Props/ledPanelSpeed/model
	}
        ....
}

Weird, I've never gotten it to work, does it work for textures? Just tried it and I can't get it to work with textures at all, though I guess if it works with models I can just put multiple models and prop cfgs in the same folder and have them share the same set of textures. Seems a better idea than having RPM turn the transforms each update.

[Mihara]

Weird, I've never gotten it to work, does it work for textures?

Yes it does.

PROP
{

    name = IndicatorPanelRPM

	MODEL
	{
		model = Squad/Props/IndicatorPanel/model
		texture = model000,JSI/RasterPropMonitor/Library/Props/IndicatorPanelReplacement/model000
		texture = model001,JSI/RasterPropMonitor/Library/Props/IndicatorPanelReplacement/model001
	}
....

[K3-Chris]

I've never gotten it to work

	MODEL
	{
		model = B9_Aerospace/Props/B9_Gauges/model
		texture = b9altimeter,B9_Aerospace/Props/test/b9altimeter
	}

And yes that file exists:

GameData\B9_Aerospace\Props\test\b9altimeter.tga

If I remove that line and move the .tga back to the folder the .cfg is in it works again, it's very strange. I get it to work on parts just fine, but never props for some reason.

Well I've re-saved the model with the adjustments to the rotations I wanted in the same folder as the previous model and defined the use of that model in the other prop, works fine, it's really weird though why I can't assign textures to props, this isn't the first time I've tried and failed, and again I can do it just fine with parts.

Edited August 7, 2014 by K3|Chris

[Mihara]

If I remove that line and move the .tga back to the folder the .cfg is in it works again, it's very strange. I get it to work on parts just fine, but never props for some reason.

The catch is that the models will not load if all textures the names of which are compiled into the MU file are not found directly where the model is -- regardless of how the model is used after that, the model loader is silly.

The workaround is to keep dummy files of minimal possible size, which is 32x32 pixels at 24 bits, in the same directory as the model, with names the same as what is compiled into the model. Then substitute real textures with MODEL {} when you actually use the model in a prop/part/whatever.

[K3-Chris]

Weird, I don't have to do that with parts.

[Mihara]

Weird, I don't have to do that with parts.

Might be an illusion, but regardless, since when anything in KSP internals is sane anway?

[nli2work]

HURRAH, all is working now. I don't know why, I don't care. I think I have an idea why, at least with the buttons using ActionGroupSwitch.... but I'm not going to spend another 2 hrs to test.

RPM heard I asked you about looking into it and decided to work properly. The power of fear. LOL

[K3-Chris]

Might be an illusion, but regardless, since when anything in KSP internals is sane anway?

Yeah it's weird, testing it now and you're right, "fake" stand-in texture works for props, not needed for parts, something in parttools must be wonky for props I guess, must be checking for the file in the original folder even if you use MODEL{texture}

Anyway, I got a radar alt gauge with a light using "ALTITUDEALARM" (130m radar alt, negative vertical speed) but that vertical speed could use some tweaking, it's sensitive enough to trigger going down the runway level, I haven't seen the actual code but I assume it checks for negative vspeed, not say -0.5m/s or something like that, would be a nice improvement to stop my altitude alarm going off.

[Mihara]

Anyway, I got a radar alt gauge with a light using "ALTITUDEALARM" (130m radar alt, negative vertical speed) but that vertical speed could use some tweaking, it's sensitive enough to trigger going down the runway level, I haven't seen the actual code but I assume it checks for negative vspeed, not say -0.5m/s or something like that, would be a nice improvement to stop my altitude alarm going off.

This is trivial, but I won't be able to add that into a published release in the immediate future, (like ten days or so) I'm afraid.

[K3-Chris]

Heh obviously not asking you to fix it right now, slot it into your todo list and include it in whatever release happens next, much appreciated.

[FluffySilverUnicorn]

@Mihara

You probably don't have very much control over this, but I should point out that the StarSystems mod breaks RPM. I have triple checked that everything is installed correctly, and it still breaks. I love your mod and I use it all the time, so I hope to see it become compatible in the future.

Without StarSystems:

With StarSystems:

[FluffyBob]

Just want to add another thank you for this tremendous Mod. I have been launching, docking, landing in IVA and just loving it. This has done so much more for immersion for me than career mode and 'science'. I remember seeing Orbiter's MFD's in Bobcat's old rover and realizing how much this game was missing functioning MFD's.

Do we have a showcase anywhere of mods using RPM / props other users have made? I have checked out everything in the OP. Searches on Curse don't seem to turn up much.

[Mihara]

@Mihara

You probably don't have very much control over this, but I should point out that the StarSystems mod breaks RPM. I have triple checked that everything is installed correctly, and it still breaks. I love your mod and I use it all the time, so I hope to see it become compatible in the future.

Then talk to the author of StarSystems to make it stop crashing and breaking the initialization chain. Show them this post: http://forum.kerbalspaceprogram.com/threads/57603-0-24-2-RasterPropMonitor-putting-the-A-in-your-IVA-%28v0-18-1%29-27-Jul?p=1297893&viewfull=1#post1297893

This is utterly impossible to fix on the RPM end.

Do we have a showcase anywhere of mods using RPM / props other users have made? I have checked out everything in the OP. Searches on Curse don't seem to turn up much.

Not really. People rarely think to post here about the things they made with RPM these days.

[K3-Chris]

People rarely think to post here about the things they made with RPM these days.

Still WIP but still:

Javascript is disabled. View full album

B9 HL Cockpit IVA

Still uses some ASET props and stock props, will use all custom b9 props before release of B9 5.0 (same props going into other B9 IVAs as well).

Stock props, aset props, the lights etc are all placeholder.

Only needed about a million questions posed to Mihara, days of reading the RPM documentation and a billion more questions asked on the IRC and another million questions asked of alex to make it.

Edited August 9, 2014 by K3|Chris

[MrWizerd]

Still WIP but still:

http://imgur.com/a/pp82W

B9 HL Cockpit IVA

Still uses some ASET props and stock props, will use all custom b9 props before release of B9 5.0 (same props going into other B9 IVAs as well).

Stock props, aset props, the lights etc are all placeholder.

Only needed about a million questions posed to Mihara, days of reading the RPM documentation and a billion more questions asked on the IRC and another million questions asked of alex to make it.

THAT is beautiful!!!!! Kudos!

Does anyone know if there is a CFG file that adds the docking camera function, I have not been able to find it.