Jump to content

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

Mihara

By Mihara
in KSP1 Mod Releases

 Share

Recommended Posts

guims

guims

Posted
Posted

Hi everyone!

First of I have to apologize for my english, but I will try my best here:wink:) and to make a simple copy of this message on
"
[v.25]RetroFuture v1.7.2 - so long 2014"

Like most of you I spend couple of weeks (months ?) to make my modded KSP version work...I use JSGME for some who know it, it's really usefull and give you the possibility to install or uninstall mods very quick, with original files backups...Plus it tells you if a mod overwrites another's files. That's an advice, seriously it works fine.

whatever...

since few days, Ican finally play more than two ore three hours with no CTD or onther bad stuff! Yeeehaaa.

whatever...

The only issue I have is this:

In VAB, I can read"JSIActionGroupSwitch: INITIALIZATION ERROR, please check configuration."

With this, I can see strange things on the RPM IVA screen like infinite number list or weirds textures pictures files, don't know how to call it, and can't push any buttons...

Simply, RPM just does not work. and only happens with the transparent pods. (usually use the cyclopod which is awesome)

And by the way in forgot to mention that I wanted to post a screenshot but don't understand how to use url.

Link to comment
Share on other sites
djnattyd

djnattyd

Posted
Posted

This has probably been addressed already but how exactly do I implement the transparent window function? I'm looking at the documentation but I'm not sure how I find what the name of the transforms are. This is for the default mk1-2 pod.

Link to comment
Share on other sites
nli2work

nli2work

Posted
Posted
This has probably been addressed already but how exactly do I implement the transparent window function? I'm looking at the documentation but I'm not sure how I find what the name of the transforms are. This is for the default mk1-2 pod.

it doesn't really work with stock pods. Squad's command pods are not set up to work with TransparentPod module

Link to comment
Share on other sites
nli2work

nli2work

Posted
Posted
I have a bug with the IVA views displaying outside the craft, half embedded in the ground.

that happens when you have a TransparentPod part in physics range, and the other pods don't have the proper config patch applied.

most probable cause is JSI isn't in GameData/; or you don't have ModuleManager installed.

Link to comment
Share on other sites
artwhaley

artwhaley

Posted
Posted (edited)

As I fiddled with the target relative distances and angles, I was thinking about how to add docking guidance to the MFD, as it seems like a pretty commonly requested thing, especially in the thread about NavyFish's plugin.

I'd like to implement something very similar to NavyFish's plugin instrument, but as a MFD screen for IVA. It would consist of vertical and horizontal position needles, a relative rotation bug, and a relative velocity bug. Ideally, I'd like to lay these on top of the docking port camera view. I showed in my pull request on the corrections to the relative angle and velocity calculations how I'd been playing with doing it via variable animation, but even with refresh set to 1, it's jerky... and it doesn't work with an mfd, it's just a series of parts that sit in front of the video monitor and animate in response to the variables. So it will only work on a custom built prop...

Obviously, it would be better built into a background handler so people could just call it from the config file, instead of building a prop with 4 objects and 2 nulls to do it like I did in that demo.

First question, is this an okay thing for me to make and pull request into the project? I can, of course, make an addon RPM DLL that just contains my handler... but it seems like a lightweight feature that nobody would hate having, so I'd rather roll it into RPM, if that's okay with you guys?

I could either build a new handler that copies most of the functionality of the steerable camera and adds the docking needles and icon on top of that, or I could add the functionality to the steerable camera handler. The second option seems better to me, as it probably only adds 50 lines of code to the project, but I'm open to doing it whichever way you guys prefer.

My thought is, if I insert it into the steerable camera handler, whenever it detects that the reference camera is CurrentReferenceDockingPortCamera, it would draw the indicators. That way it would just work in any mod's docking camera reference screen, as soon as the user updates RPM. I could add a KSPField to disable it, so anyone that wanted their prop to show the docking port camera without the docking guidance would be able to.

My other question is - should the docking port guides stay fixed in the display, regardless of how the user has the camera panned, tilted or zoomed... or should they move with the camera, the way the crosshairs do at the moment? My personal preference is for them to stay centered on the screen, as you could still dock even while you used the camera to inspect something else... and it's easier to code that way too.

So, the TL;DR questions -

1. May I make a docking port alignment guide to go into the RPM project?

2. Would you like it in it's own handler that duplicates the camera code, or may I add it to the steerable camera?

3. Should it default to on whenever it sees you using the docking port reference camera (with a config file option to disable the feature), or should it default to off and only show up if the config file turns it on?

4. Should the guides stay centered on the display or move and possible get clipped off the screen if the camera is panned or tilted?

Thanks - and if you guys would prefer I not "help out" don't hesitate to say so! I totally understand that it's your project and I don't want to elbow my way into it. I just learned a lot looking at your code, and would love to contribute a little if I can be of use!

Here's the video of me doing it with custom animated props, for those that don't follow the RPM Gitub

Art

Edited by artwhaley
Link to comment
Share on other sites
Themorris

Themorris

Posted
Posted
As I fiddled with the target relative distances and angles, I was thinking about how to add docking guidance to the MFD, as it seems like a pretty commonly requested thing, especially in the thread about NavyFish's plugin.

I'd like to implement something very similar to NavyFish's plugin instrument, but as a MFD screen for IVA. It would consist of vertical and horizontal position needles, a relative rotation bug, and a relative velocity bug. Ideally, I'd like to lay these on top of the docking port camera view. I showed in my pull request on the corrections to the relative angle and velocity calculations how I'd been playing with doing it via variable animation, but even with refresh set to 1, it's jerky... and it doesn't work with an mfd, it's just a series of parts that sit in front of the video monitor and animate in response to the variables. So it will only work on a custom built prop...

Obviously, it would be better built into a background handler so people could just call it from the config file, instead of building a prop with 4 objects and 2 nulls to do it like I did in that demo.

First question, is this an okay thing for me to make and pull request into the project? I can, of course, make an addon RPM DLL that just contains my handler... but it seems like a lightweight feature that nobody would hate having, so I'd rather roll it into RPM, if that's okay with you guys?

I could either build a new handler that copies most of the functionality of the steerable camera and adds the docking needles and icon on top of that, or I could add the functionality to the steerable camera handler. The second option seems better to me, as it probably only adds 50 lines of code to the project, but I'm open to doing it whichever way you guys prefer.

My thought is, if I insert it into the steerable camera handler, whenever it detects that the reference camera is CurrentReferenceDockingPortCamera, it would draw the indicators. That way it would just work in any mod's docking camera reference screen, as soon as the user updates RPM. I could add a KSPField to disable it, so anyone that wanted their prop to show the docking port camera without the docking guidance would be able to.

My other question is - should the docking port guides stay fixed in the display, regardless of how the user has the camera panned, tilted or zoomed... or should they move with the camera, the way the crosshairs do at the moment? My personal preference is for them to stay centered on the screen, as you could still dock even while you used the camera to inspect something else... and it's easier to code that way too.

So, the TL;DR questions -

1. May I make a docking port alignment guide to go into the RPM project?

2. Would you like it in it's own handler that duplicates the camera code, or may I add it to the steerable camera?

3. Should it default to on whenever it sees you using the docking port reference camera (with a config file option to disable the feature), or should it default to off and only show up if the config file turns it on?

4. Should the guides stay centered on the display or move and possible get clipped off the screen if the camera is panned or tilted?

Thanks - and if you guys would prefer I not "help out" don't hesitate to say so! I totally understand that it's your project and I don't want to elbow my way into it. I just learned a lot looking at your code, and would love to contribute a little if I can be of use!

Here's the video of me doing it with custom animated props, for those that don't follow the RPM Gitub

Art

WOW! Thats amazing! This should definitly be stock RPM, also the NavUtils Landing Guidance should be.

Link to comment
Share on other sites
MOARdV

MOARdV

Posted
Posted
So, the TL;DR questions -

1. May I make a docking port alignment guide to go into the RPM project?

2. Would you like it in it's own handler that duplicates the camera code, or may I add it to the steerable camera?

3. Should it default to on whenever it sees you using the docking port reference camera (with a config file option to disable the feature), or should it default to off and only show up if the config file turns it on?

4. Should the guides stay centered on the display or move and possible get clipped off the screen if the camera is panned or tilted?

I'll throw in my 2 cents since I did the steerable camera (Mihara may or may not agree). Yes, please.

Please open an issue on GitHub, and I'll put my feedback on the design in it - I don't want to put a wall of text on a feature design in the forum. :) I'll also look over your pull request, since Mihara hasn't folded that into the repository yet.

Link to comment
Share on other sites
VentZer0

VentZer0

Posted
Posted

I love RPM. I have a suggestion for it. A target cam MFD screen. Similiar to the target cam in Lazorsystem, but as a MFD and not as part of the GUI.

Basically a camera that can be moved around like any other camera part through MFD interaction. Just that it locks on to your target as soon as you set it and then tracks it with a stabilized view. A secondary mode could be that you can move the camera to a spot on the ground which creates a virtual target and the cam will track this spot too. Right now in Lazorsystem you have to target a vessel or object to have a real tracking target for the laser and the target cam, so if you target the ground, the laser willjust continue looking in that irection but will not track a particular spot.

Something like this would be awesome, having some functioning recon- or lantirn-pods available.

Link to comment
Share on other sites
Kerbrud

Kerbrud

Posted
Posted

Hello, Mihara!

I'm trying to reverse-engineer some of the code that Hyomoto used for his MFD, but I'm actually having a hard time understanding C#. Apart from the "string.format" site you've linked to on Github, could you, or someone else, please provide a syntax-explanation as to how the code works?

An example is this:

{0,-6:"[#00ff00ff][GEAR][#ff5050ff]";0;[GEAR]} $&$ GEARALARM

In sudo-code, I would say this piece of code says: "FOR variable zero print "[#00ff00ff][GEAR]" IF variable zero is 0 OR print "[#ff5050ff][GEAR]" IF variable zero is 1"

That's all fine and dandy, but an example of which bit puzzles me, is the "-6" and the syntax in general.

Thanks in advance!

Link to comment
Share on other sites
Kerbrud

Kerbrud

Posted
Posted
IIRC, the -6 is for text alignment; positive is left align; negative is right align. the rest is as you figured it.

I found out what the error was:

{0,-6:"[#ff0000ff][GEAR ]";;"[#00ff00ff][GEAR ]"} and the syntax is

{VARIABLENUMBER,TEXT-ALIGN:"STRING_FOR_RECIEVAL_OF_TRUE";;"STRING_FOR_RECIEVAL_OF_FALSE"}

^"for" ^"switch"

...or something in that manner.

Still, how do you guys figure this syntax?

{1:;"";""}{0:"[#FF0000FF]OVERSPEED";"";""} $&$ DOCKINGSPEEDALARM TARGETEXISTS

Specifically, what's the deal with the second set of ' ";"" ' ?

{1:;"";""} in sudo is "if variable 1 returns 1, print whatever is inside the first pair of " " but what is the second?

{0:"[#FF0000FF]OVERSPEED";"";""} in sudo is "if unplanned disassembly is imminent due to variable 0 returning 1, print whatever is inside the first pair of " " but what is the two other pairs supposed to do?

Link to comment
Share on other sites
BahamutoD

BahamutoD

Posted
Posted (edited)

I have a suggestion for a small improvement to the zooming behavior of JSISteerableCamera. Currently, it zooms by linearly sliding the field of view. The problem with this is the rate of zoom gets faster as the current zoom level increases.

In other words, the more you zoom in, the quicker the zoom responds to inputs. When you're all the way zoomed out, it takes forever to zoom in.

I fixed this problem in in my CameraTools mod by using an exponential function.


zoomFactor = Mathf.Exp(zoomExp)/Mathf.Exp(1);
manualFOV = 60/zoomFactor;

With this, linearly increasing 'zoomExp' will make it so the camera appears to zoom linearly, with zoomExp = 1 giving you a standard 60deg field of view.

I'm uploading a video demonstration.

edit:

Edited by BahamutoD
It was the opposite
Link to comment
Share on other sites
nli2work

nli2work

Posted
Posted
how would I get ext1-10 camera views on an unmanned craft? I have a Delta IV heavy and mounted 2 JSI cameras but no way of seeing them?

right click on the external camers and set them to different ID # with the +/- buttons.

Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...