Jump to content

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


Mihara

Recommended Posts

Got two bugs over here:

rectangular curve:

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

underground trajectory (peryapsis was about 73km)

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

They're artifacts of the orbit rendering algorithm. For the sake of simplicity, I break the ellipse into a number of line segments (controlled by orbitPoints in the JSIOrbitDisplay config). The ellipse is then rendered using that number of segments - except that I subdivide the orbit by time, instead of by distance along the curve. And, since a body moves faster closer to the periapsis, it tends to show segmentation at that point. One of my planned improvements for the orbital display is to find a better heuristic for subdividing. In the mean time, raise orbitPoints higher. I think 120 is the default. I use 180, personally, but high eccentricity will still show that problem.

Link to comment
Share on other sites

As far as the button is concerned, you may have overlooked something. Once in space, I may want to turn it off altogether if that information is no longer relevant, or provide an entirely different sheet of information.

Well, the screen can be defined as a button, IIRC...

Next up, I assure you, I am using a transparent layer in Photoshop (I'm using PNGs). But transparency doesn't seem to work correctly.

Something's messed up in the shaders. This will need more in-depth investigation that is going to take a while.

Most probably, RPM actually needs some custom shaders... :)

While landing for the first time on Minmus, I noticed some discrepencies between the horizontal speed given by RPM (left) and the one from Ingeneer (right). A crude estimate while looking at the landing by the external view is that engenieer is a better estimate, but why the difference?

RPM uses MechJeb code for most of variable data, if only because license matches -- I can freely import MechJeb code, but I can't do the same with Engineer except for the most obvious cases. If it says the same as what MechJeb says about a certain value, I consider it correct.

Does MechJeb match?

That's most probably it. Last time I checked a fair few of RPM's variables are mismatched with their labels. The dry/wet mass labels in the info tab seem to be reversed for example.

Oops. Fixed. They really are just mismatched with the labels.

Is there any way to turn off the debug log spam for this mod? I get something like this every time I switch to a new craft (there's actually a lot more during every craft switch, this is cut down to fit into the post), which makes it hard to watch any possible interactions between what I am trying to write and other mods. Most of this seems to be purely informational.

No, there isn't. I find this tremendously helpful when people ask me why X doesn't work -- it doesn't spam it every frame, just every initialization.

I'll see about some kind of global debug switch though...

Link to comment
Share on other sites

They're artifacts of the orbit rendering algorithm. For the sake of simplicity, I break the ellipse into a number of line segments (controlled by orbitPoints in the JSIOrbitDisplay config). The ellipse is then rendered using that number of segments - except that I subdivide the orbit by time, instead of by distance along the curve. And, since a body moves faster closer to the periapsis, it tends to show segmentation at that point. One of my planned improvements for the orbital display is to find a better heuristic for subdividing. In the mean time, raise orbitPoints higher. I think 120 is the default. I use 180, personally, but high eccentricity will still show that problem.

The stock KSP actually use this too and has the same issue. It's normally seen when the ecc of the orbit is very big.

One small "bug" I would like to mention is: the TextMenu class will clamp the label text according to the width given in the ShowMenu() function, but if there're color tags in the label text, though it won't even occupy the right edge of the screen, it will still be clamped.

Link to comment
Share on other sites

The stock KSP actually use this too and has the same issue. It's normally seen when the ecc of the orbit is very big.

One small "bug" I would like to mention is: the TextMenu class will clamp the label text according to the width given in the ShowMenu() function, but if there're color tags in the label text, though it won't even occupy the right edge of the screen, it will still be clamped.

As I recall, I wrote the TextMenu class before embedded tags were around, or maybe before I was aware of them. I'll file an issue on github to remind me to address that.

Link to comment
Share on other sites

No, there isn't. I find this tremendously helpful when people ask me why X doesn't work -- it doesn't spam it every frame, just every initialization.

I'll see about some kind of global debug switch though...

I'm sure it is very useful; I leave a few debugging symbols in myself and find them highly useful in testing environments. I have no issue with it being on by default, I am really just asking for a way to supress it. Thanks.

E: I'll just get your latest source and commit some of the changes I'd like to see.

Edited by regex
Link to comment
Share on other sites

Hi Mihara, I've just installed this (while also installing SCANsat), and suddenly found that shortly after liftoff my rocket explodes (or more like disappears) and the camera flies off into space. I uninstalled both mods, but the problem persists.

Is there anything I can do?

EDIT: I uninstalled FAR and now it seems to work, is this a known problem?

Edited by junkie_business
Link to comment
Share on other sites

Hi Mihara, I've just installed this (while also installing SCANsat), and suddenly found that shortly after liftoff my rocket explodes (or more like disappears) and the camera flies off into space. I uninstalled both mods, but the problem persists.

Is there anything I can do?

EDIT: I uninstalled FAR and not it seems to work, is this a known problem?

I've had this happen before, i haven't been able to figure out what it was (maybe kerbal joint reinforcement), I updated AEIS and it hasn't happened scnce

Link to comment
Share on other sites

I don't know if this has been reported before, but I don't have the stamina to read 25 pages:

The buttons on the displays (and thus the displays themselves) stops working if you have crew in a part that doesn't have an IVA view attached to your ship, for example the b9 crew tanks, empty ones are fine, add a single kerbal to them and the displays go dead in the cockpit, tested it with parts from a lot of different packs and stock parts, consistent behavior.

Link to comment
Share on other sites

I don't know if this has been reported before, but I don't have the stamina to read 25 pages:

The buttons on the displays (and thus the displays themselves) stops working if you have crew in a part that doesn't have an IVA view attached to your ship, for example the b9 crew tanks, empty ones are fine, add a single kerbal to them and the displays go dead in the cockpit, tested it with parts from a lot of different packs and stock parts, consistent behavior.

I thought this was fixed? Have you tried updating?

Link to comment
Share on other sites

Now I'm literally playing the game without time-warp, I've been in a 100 km orbit for 20 min. without time-warp.

This is beyond cool!

EDIT:

Now I just made my first manned orbit in my new save( I deleted the old), was made with IVA!

Seriously, you won the cake

Edited by EuSouONumero345
It's clearly visible :D
Link to comment
Share on other sites

Damn you for being awesome! I read the issue and that sounds about right. On the heading bar, that should represent slip well enough. The only recommendation I would make is, if possible, allowing us to either choose the color of the indicators, or draw the indicators ourselves. Based on your previous work I expect that was already the case, but it doesn't hurt to bring it up :)

This took me longer than I expected, but it's now a pending pull request, once Mihara has a chance to review it and update the dev build. I'm using the prograde icon to keep consistent with the navball behavior, but color is configurable.

I put together a few other tweaks, but they're all focused on JSIOrbitDisplay and MechJebRPM*.

Link to comment
Share on other sites

Just played after a few weeks of being busy, and oh my goodness, the new features! The orbital displays! The huds! The awesome!

However, I was playing around with the new HUD, and I encountered something rather odd. When I reduced the transparency level of the HUD background to increase clarity (which totally works--it's much prettier with backgroundColor = 0,0,0,5 than by default), the Prograde marker becomes almost invisible! Anywhere that it intersects other markings, such as the horizon or staticoverlay, it is clearly visible. It seems to be drawn as some sort of photoshop-style overlay (like multiply or subtract or whatever) instead of simply drawn on the screen at the alpha designated by the command "progradeColor = 214, 250, 0, 255" or whatever.

Is there any chance I can get it to draw with a static alpha, instead of its visibility depending on the alpha of the image behind it? Either as a setting or the new default. Thank you!

EDIT: I have a question. If I wanted to make the HUD itself a button, so that clicking on it toggles it to a different page, how would I best go about doing that?

Edited by S.O.P.H.I.A.
Link to comment
Share on other sites

Is there any chance I can get it to draw with a static alpha, instead of its visibility depending on the alpha of the image behind it? Either as a setting or the new default. Thank you!

Not currently. This is basically a shader problem, (things painted on a RenderTexture are painted with a shader, alas) which is ultimately best solved by creating a new shader.

Soon, hopefully. A naive solution "let's just copypaste something off a wiki" didn't work as I hoped (and neither it allowed me to make B&W cameras even though the basic mechanic was perfectly sound) so it needs more research. :)

EDIT: I have a question. If I wanted to make the HUD itself a button, so that clicking on it toggles it to a different page, how would I best go about doing that?

Every collider can be a button. You just need a collider that covers the entire model.

Link to comment
Share on other sites

I just downloaded the newest KSP Interstellar version .10.1 and the monitors are no longer working. In the ALCOR capsule I'm getting this...

wrOWvf3.png

In the stock capsules the screens are just grey and blank. I have it narrowed down to the OpenResourceSystem folder that is included with Interstellar causing the conflict. I am not sure why these would be conflicting, however any ideas on how to make them work would would be great. Thanks

Edited by SandmanX
Link to comment
Share on other sites

In the stock capsules the screens are just grey and blank. I have it narrowed down to the OpenResourceSystem folder that is included with Interstellar causing the conflict. I am not sure why these would be conflicting, however any ideas on how to make them work would would be great. Thanks

If pressing buttons on the display buttons doesn't clear it up, it sounds like ORS is doing something that is preventing RPM from running correctly. Without looking under the hood at ORS, I wouldn't begin to guess what's going on. Maybe Mihara will have a better idea.

Link to comment
Share on other sites

Imma drive-by your thread since I figure the people watching it might be interested in this:

.........

Very work-in-progress, but there you go.

May i say, that looks very very nice.

EDIT:

The other pictures look great as well btw.

It makes KSP more enjoyable if you want to fly from the inside, like i do. An alignment indicator was already a blessing, but seeing an improved cockpit will win me over to download some extra things.

Edited by fastbikkel
Link to comment
Share on other sites

In the stock capsules the screens are just grey and blank. I have it narrowed down to the OpenResourceSystem folder that is included with Interstellar causing the conflict. I am not sure why these would be conflicting, however any ideas on how to make them work would would be great. Thanks

Well, posting your KSP_Data/output_log.txt would be a start. I don't see anything obvious about OpenResourceSystem that would cause it, but obviously, something kills the update thread before it gets to the monitors...

EDIT: Installed OpenResourceSystem without the rest of Interstellar, launched an ALCOR... Cannot reproduce the problem on the ground.

Edited by Mihara
Link to comment
Share on other sites

Deleting OpenResourceSystem removed the errors. However, after much trial and error I discovered OpenResourceSystem was not getting along with an outdated version of Active Texture Management causing my problems. I apparently hadn't upgraded to version 2-15 when I thought I had. Thank you for this amazing mod.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...