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

[MOARdV]

Nazari1382 - thanks for the pointer. I'm not clear how to do that (I have Unity installed, and part tools 18, but I can't seem to load the .mu file into a project). However, that's outside of the scope of this thread, so I'll go poke around elsewhere on the forum and see if I can get clues on where I go from here.

[Mihara]

Nazari1382 - thanks for the pointer. I'm not clear how to do that (I have Unity installed, and part tools 18, but I can't seem to load the .mu file into a project). However, that's outside of the scope of this thread, so I'll go poke around elsewhere on the forum and see if I can get clues on where I go from here.

It's fairly self-evident how to do that using PartTools 20. It just gives you a menu to load capsule internals, and a menu of props to spawn in them, you see them exactly as they appear in the game, so it's quite easy to do, and it saves straight to the IVA config files as well. With PartTools 18, it's a huge pain, I'm told.

[MOARdV]

It's fairly self-evident how to do that using PartTools 20. It just gives you a menu to load capsule internals, and a menu of props to spawn in them, you see them exactly as they appear in the game, so it's quite easy to do, and it saves straight to the IVA config files as well. With PartTools 18, it's a huge pain, I'm told.

That must be it - I grabbed .18 tools some time ago, looked at Unity for 5 minutes, and never bothered updating, since I'm not a modeler.

[OrianCEV]

Very nice mod,Makes IVA much more interesting.

Edited November 28, 2013 by OrianCEV

[xxbairdixx]

A call for support:

I'm debugging SCANsat integration. That is, the very first prototype even works, but I'm not sure it's actually getting the data. Unfortunately I haven't had the time to play KSP at all in the past month with all this coding.

Could anyone produce a save file with no vessels at all in it, but Kerbin having been scanned in as much detail as possible? That would save me quite some time.

EDIT: That should get you interested.

so since you were able to get scansat working do you think it would be possible to implement the games map view for the current SOI for viewing predicted trajectories

[Mihara]

so since you were able to get scansat working do you think it would be possible to implement the games map view for the current SOI for viewing predicted trajectories

TLDR: Nope, I have tried already and there's apparently no way in hell.

Longer explanation: In KSP, not only the world rotates around you (that is not so uncommon in games) but also, there are multiple layers of indirection -- you fly within Krakensbane, which is a special moving bubble where the world is "real" which exists to reduce scales and speeds to levels which the physics engine can cope with, but that itself is on a Keplerian orbit within ScaledSpace, where planets exist as small scale models. (And you thought Kerbal planets were already small). Once you move close enough to a planet, the scale model is replaced with the actual planet generated on the fly. The map view does not exist separately, it is the ScaledSpace itself. When you zoom out while looking at that -- and ONLY while looking from the map view -- orbits and markers are painted in. I.e. there is no camera I could grab that sees them until the map view is turned on, because they don't exist, and when they exist, IVA can't be seen.

Since there's no shortcut, the only way to show it on the monitor screen would be to replicate yet another very very small copy of the solar system somewhere in the bowels of the ship, draw all the orbits on THAT, and point a camera at it, which, beyond reimplementing a sizeable portion of KSP code, would involve far more math than I'm capable of.

I did everything I could to enable someone else to do it by making the monitor pluggable. If someone mathematically inclined knows how to draw it from the available data, they can make their own module that does it and stitch it into RasterPropMonitor easily without ever worrying about my code -- but that someone is not me.

[xxbairdixx]

awww shucks oh well thanks for the explanation

[xxbairdixx]

i was thinking would it be possible for you to make a monitor part so for instance you could place it inside hollow structures to make bases and custom command modules

[Mihara]

i was thinking would it be possible for you to make a monitor part so for instance you could place it inside hollow structures to make bases and custom command modules

In theory, yes it would be possible.

In practice, the distinction between InternalModule and PartModule makes it nontrivial to do without duplicating most of the code, which makes it unlikely that I will get up to it any time soon.

[Mihara]

Accidental new feature.

No, seriously, I didn't expect I could do this until just two hours ago.

[sirkut]

Hahah. Next thing you'll add piglatin and 1337 speak filters.

[Mihara]

Hahah. Next thing you'll add piglatin and 1337 speak filters.

No, I never could understand the rules of pig latin, and don't really understand how it's supposed to be a thing for children to do in their head.

[Pingonaut]

Can someone post an image showing exactly what buttons do what? I can't figure out how to switch between docking ports or even cameras (the ones included with the ALCOR mod)

[Mihara]

Can someone post an image showing exactly what buttons do what? I can't figure out how to switch between docking ports or even cameras (the ones included with the ALCOR mod)

If you're talking about this particular prop, a) it's not set up for the camera part that comes with ALCOR anyway, and such a screenshot is going to be completely obsolete in a few hours when I'm done tuning the new one.

[MOARdV]

I've spent waaaaay too much time tinkering with building my own pages for an adaptation of the example display in the KOSMOS VA Command Pod (BTW, Mihara, thanks for pointing out that I should use PartTools 0.20 - I had 0.18, which is why I couldn't figure it out). I do have some feedback / questions:

1) Would you consider changing all of the formatted time variables to include a space for the sign? Currently, TIMETOAP doesn't leave a space for the sign, but TIMETOPE does, so if I line the format strings up with the {0} directly above one another, the line with TIMETOPE looks like it is offset by one. Even if the TIMETOAP never has a negative value, adding the extra space ensures that the "time" strings will line up. Same request with other times, even if they're never negative.

2) Is there any way to get the existing buttons (for the ALCOR module, for instance) to behave as single-position buttons (one that doesn't switch between on and off, but instead act like the 'stage' button should)? I'd like to add some buttons that I could use for the SCANsat extensions, once that's ready for release, and I don't think toggle buttons are appropriate. I'm not a modeler, so I'm not sure how to get started along that avenue.

[Mihara]

1) Would you consider changing all of the formatted time variables to include a space for the sign? Currently, TIMETOAP doesn't leave a space for the sign, but TIMETOPE does, so if I line the format strings up with the {0} directly above one another, the line with TIMETOPE looks like it is offset by one. Even if the TIMETOAP never has a negative value, adding the extra space ensures that the "time" strings will line up. Same request with other times, even if they're never negative.

While I have OCD as much as the next KSP player, there's a reason for this particular one: since it can never be negative, it's better to leave no space, because the user might want to display it separately from TIMETOPE and need that space.

Someday, when I'm feeling particularly bored (next week, maybe) I'll write a Kerbal time formatter extension that will take care of that problem for good by making time format definable in the page itself, so you can leave off the years if you feel like it, print a heart instead of a sign, etc.

2) Is there any way to get the existing buttons (for the ALCOR module, for instance) to behave as single-position buttons (one that doesn't switch between on and off, but instead act like the 'stage' button should)? I'd like to add some buttons that I could use for the SCANsat extensions, once that's ready for release, and I don't think toggle buttons are appropriate. I'm not a modeler, so I'm not sure how to get started along that avenue.

I'm not clear what exactly do you mean by a 'single position button'. One that does not stay toggled, but immediately snaps back after being triggered once?

If you mean the JSIActionGroupSwitch-driven buttons, that's trivial to do but I can't understand why would you want to do it, because none of the things it can toggle actually behave this way -- and it can't toggle handler plugins, so they would not be useful for driving SCANsat integration.

If you mean buttons on the monitor props, none of them actually switch between on and off -- they make the page "active" and then become ignored until a button activates a different page.

If you mean buttons on monitor props that control handler plugins, those have been working for a while and the SCANsat extension is the first one to use them -- they are made exactly like normal monitor buttons and their action is defined by the plugin that handles the current page (if any).

...And I'm going to be done tuning the 0.9 release with SCANsat support in it any time now.

[Mihara]

Bump for release! Muahahahaha.

RasterPropMonitor 0.9 released.

Bugs fixed:

1. Monitor would choke on pages which contained no sources of text. Not anymore.
   
2. When switching from a page with a working camera to a page where a camera is missing, the screen would keep showing the working one. Fixed.
   
3. An obscure API issue has been caught before anyone but me used it, whee.
   
4. Some inconsistencies which could have hindered using transparent colors for certain elements were corrected, if you previously tried to make a transparent display and it didn't work, try again the same way.
   

New features:

1. I promised SCANsat integration, and here it is, for suitably small values of "here": Meet JSISCANsatRPM. I'd wager those suitably small values will suffice for just about anyone, though. There probably still are some bugs in it. It will obviously remain inactive if SCANsat is not installed.
   
2. Colortags! All text on the monitors can now be colorised letter by letter by using [#rrggbbaa] color sequences in the text -- see the documentation. Associated changes make it easier to create a transparent display, since default text transparency can also be set.
   
3. JSISetInternalCameraFOV module can help you get around the fact that the FOV of IVA cameras is not configurable and fisheye deformation can be too high for some pod layouts.
   
4. By popular demand, slope of the surface in degrees is now available as a variable. Also, biome name. (Exactly the way MechJeb displays it). Also a shortened biome name for when you can't be bothered to use the full one.
   
5. Pages with background handlers that could not be loaded (for example, if JSISCANsatRPM did not load, because the user doesn't have SCANsat) will now fallback to camera or texture background if those are also present in the page configuration. The same thing will happen with page handlers -- if the handler did not load, the page will fallback to text defined by other means.
   
6. The example prop is replaced by the new MFD courtesy of alexustas, which lets me enable the navball plugin and the map plugin on it -- there's enough buttons now and some are left over. The old example prop will continue working if you installed it into any other pods, unless you do the silly thing and delete it.
   

There are no breaking changes, unless you customised the example prop by directly editing it's config files and not using ModuleManager. But just in case, I did not delete the binaries for version 0.8.

And for everyone who's trying to incorporate it into their props: Please don't rely on example configs! They are tuned to particular props and rely on default values which might not be appropriate for your props. There's a boatload of documentation for you to read.

Edited November 30, 2013 by Mihara
typo.

[jpinard]

Holy cow this is incredible!

[Termaul]

You are the man , im about to try out the scAnsat mod with this new version. thx for the great work!

[sirkut]

I'm so far behind on playing this. Soon I tell ya! I should stop with the exterior and work on an IVA now with all these goodies.

[Commander Zoom]

Absolutely amazing work.

[Pingonaut]

This happened when I updated. Maybe I didn't delete and replace the right files or something?

[Deep silence]

<edited : i managed to make it work. It is sad the mod does not use relative path: I had removed the JSI folder and that was the cause of my problems>

This mod looks great, but It lags a lot (except for STBY, LOG, CREW pages).

There is nothing special in the debug logs, I am testing on a fresh install (windows KSP on linux), and my other install had only little lags with about 30 mods...

Edited November 30, 2013 by Deep silence

[Albert VDS]

Why aren't you using the Linux binary. I say it's no wonder it lags when you're using wine.

[Mihara]

This happened when I updated. Maybe I didn't delete and replace the right files or something?

Seeing as how you have both the old prop and the new prop it's a very obvious case of an incorrect installation. I don't know how exactly you messed it up though.

Remember: GameData directory in the package MUST match your GameData directory. Everything that is inside the GameData directory in the package must be within your GameData directory. And yes, this mod now needs two separate directories in GameData. (If there's anyone in particular to blame for this, I think it's probably N3X15, who, if my memory serves me right, is the developer who made the plugin loading mechanism that rejects plugins that call other plugins if those other plugins have not been loaded YET -- but loads them in alpabetical order.)

<edited : i managed to make it work. It is sad the mod does not use relative path: I had removed the JSI folder and that was the cause of my problems>

It can't use relative path. It relies a lot on textures loaded through GameDatabase, which KSP mandates must be named relative to GameData. Using non-absolute path for everything else would be incredibly silly as it would break anyway.

This mod looks great, but It lags a lot (except for STBY, LOG, CREW pages).

There is nothing special in the debug logs, I am testing on a fresh install (windows KSP on linux), and my other install had only little lags with about 30 mods...

This mod makes heavy use of RenderTextures. I suspect that just isn't getting emulated correctly, indeed, try the linux KSP.