MrOnak

Full map converage on the small map monitors isn't that important IMO, I just thought I point it out. Regarding the lines on the orbit assistant page: I'm not sure whether they're new or not but its the first time I noticed them

In 3.03 when I have the Thrust Plate Multi-Adapter in a stage above where I put my Fairing Base, the fairings only go up to the Thrust Plate, not all the way up to cover the top of the vessel. Is this a known bug or maybe even fixed in the later versions? Any workarounds available? Thanks in advance. Picture for clarification: update: Hmm... rebuilding that top part with the Thrust Plate and the Service Compartment fixed that.... maybe it was just a glitch.

Oooooooh yeah thats a lot better, thanks so much for this! Could the map resize tweak also applied to the maps on the small monitors? I see you fixed the velocity display bug in the large orbital view, very nice. There are two (new?) straight lines now on that view that I can't really interpret: Any hints as to what they are? Thanks also for the lighting fix for the flight directors desk. You mentioned "Fixed Map monitor pages so they are useable (needs some fixing)" - I can't seem to find a difference. What exactly did you change?

Hmmm, the small kOS part fits neatly above/below the 0.6m probe cores in my opinion. Its true, the service compartment only are 1.25m and 2.5m (although somewhere in the thread someone provided other sizes) but I find little need for compartments on tiny probes to be honest. But thats me

On the discussion of where kOS is or should be heading: As it is there are a lot of low level features missing in kOS (see my github feature requests for what I mean). Simple tools to get stuff done. Before that area hasn't been tidied up (and I applaud the progress the team is making) I think the discussion whether or not high level functionality or info x, y or z should be provided is premature. I'm not saying it shouldn't be done, I'm saying for me personally its not as important as getting the low level issues ironed out. That said, I love the way that kOS enables (or forces) me to actually understand the math behind orbital mechanics and solving the engineering problems with automatic ascend, descend, executing Hohmann transfers precisely etc. For me personally, that joy I'm having with kOS would probably be a lot diminished if I could write a two-liner to execute a maneuver node perfectly (just an example). Writing scripts for maneuver node execution, Hohmann transfers etc is relatively trivial once I figured out the math required to do so. kOS isn't lacking much in that regard for me. But that's me. I'm missing a way for other mods to hook into kOS, information where the ascending-/descending nodes of an orbit are, parameter passing between scripts and cores and stuff like that much more, and bugs with vectors and directions hurt me much more than high-ish level functions. Once those things are rectified, yeah! Why not, add high level stuff to make things easier for people who want it. Nothing wrong with that. But I don't think the time has come yet. A quick example why I think solving engineering problems are fun here, a script that executes a maneuver node that's given thru parameters: // calculates the burn time for a given maneuver node // save as executenode.txt // // call as run executenode(ETA, m/s prograde, m/s radial out, m/s normal). // i.e. run executenode(30, 200, 0, 0). declare parameter Neta, Nprograde, Nradialout, Nnormal. sas off. rcs off. // calibrate throttle lock throttle to 1. wait 0.1. lock throttle to 0. // calculate TWR lock F to (body:mu*(ship:mass*1000)) / (body:radius+body:distance)^2. lock grav to F / (ship:mass * 1000). lock TWRmax to ship:maxthrust / (ship:mass * grav). // calculate maximum acceleration of the craft in m/s lock maxAcc to ship:maxthrust/ship:mass. set burnAcc to maxAcc. // save this, since maxAcc will increase as TWR gets better during the burn // set up the maneuver set N to node(time:seconds+Neta, Nprograde, Nradialout, Nnormal). add N. // calculate burn start and end set burnTime to N:deltav:mag / burnAcc. // this assumes a constant acceleration as in burnAcc lock burnStart to time:seconds+(N:eta-(burnTime/2)). lock burnEnd to burnStart+burnTime. lock steering to N:burnvector. wait until time:seconds > burnStart. until time:seconds > burnend { // manipulate the throttle to maintain constant acceleration lock throttle to burnAcc/maxAcc. } lock throttle to 0. unlock throttle. unlock steering. remove N. While the script really isn't rocket science I'm very happy how it turned out, I learned quite a bit while writing it and it is really quite precise. That's the joy of kOS for me.

@Crown: On the off-chance that you're using the Module Manager configs which cause the issues here to get rid of the parts like MechJeb, kOS and the like, this here might be an alternative: Aside from just "hiding" parts inside the compartment tube, I found that this setup offers lots of options for "storage" if you're using KAS. Nice for a bit of role-playing as well, if you're into that sort of thing. The only slight downside is that you need to remember to assign action groups to parts inside the tube since you can't open the hatch unless through an EVA.

Oooooh thats a lot better, thanks for the quick fix!

Wow you're fast, I was just going to reply here that I saw Miharas reply . Maybe black bars on top/bottom to hide the duplicate terrain are an option after all. But remember to remove them when zooming Anyway keep up the good work, the control room is a game changer for me.

You sir, are a rocksta... wait what?! ...nevermind. Have some rep!

The SCANsat map thing is not a big deal if its hard to fix actually. Its only a bit irritating to use it as vessel position overview when the vessel isn't on the map half the time - but again, thats a luxury problem, really. If you're working on the lighting anyway, I have one glitch for you: If you have lights on the craft (in my case its the red glow from MechJeb but its probably all lights) and you timewarp the flight directors desk gets lit up during warp. Its fine for 1x warp though so its not a big issue at all but it seems like the control rooms back wall lets light in during warp

Yay! *click* [edit] OK VesselViewer works flawlessly now, thats superb, thanks. But the main monitor still only shows about half of Kerbins surface: I did delete the whole ProbeControlRoom folder before unziping the new one. Any hints? Also I noticed that the flight directors desk is now quite a bit darker, is that on purpose? Makes me want to switch on his desk lamp

Yay, goodness! Thanks for the continuous updates Nereid. BTW is there any reason why the changelog in the OP hasn't been updated in a while? That was very convenient for deciding whether to update or not.

Thanks for fixing the aspect ratio I just noticed that the map seems to auto-update when coming out of time-warp - that's good enough for me while capturing video actually.

How about sh-style backticks? log "some text" to filename. // logs to the file called filename log "some text" to `filename`. // logs to the content of the variable "filename" [edit]Yeah, I know, in sh backticks actually do something different. But it might be a non-breaking addition to kOS nonetheless. ...and its useful for other situations where I want to combine the contents of a variable with other commands.[/edit]

Thats good news, thanks Albert I have to issues / questions to report for the SCANsat incorporation, maybe I can post them both here: 1. I believe the SCANsat map doesn't quite fit into the big screen of the control room? It looks like its a bit more than half of the whole surface area. Maybe it would be possible to move the mission flags on the far sides of the wall up and shrink them a little so they fit neatly next to the mission time / vessel name displays, then move the four smaller monitors to the sides and expand the big monitor? Now that I'm writing that I realize that there might be an issue with the changed aspect ratio and the RPM monitor config.... hmmm... maybe keep the aspect ratio and size of the big screen as it is and have a black top/bottom frame instead. Anyway, food for thought 2. Is there a way to have the big SCANsat map update in intervals just like the small one already does? For the normal SCANsat operation it doesn't really matter but in the ProbeControl Room it really makes a difference for the first few missions when the body isn't fully scanned yet. This is from the view of a full-IVA-while-recording-video point of view, to be honest I'm not sure how big the difference for other people would be .

@Camacha yes it works perfectly by now: log "my concatenated datastring with variables in the middle" to logfile. Very useful for debugging OR load other scripts dynamically with this trick: // loads a script based on the name given declare parameter scriptName. log "copy " + scriptName + " from archive." to tmpcmd. log "run " + scriptName + "." to tmpcmd. log "delete " + scriptName + " from 1." to tmpcmd. run tmpcmd. delete tmpcmd.

I end my scripts by using "break" to exit the main loop. Of course that assumes that your script runs in a loop, but mine tend to do that. Alternatively I use "until AG10=on {}" or something similar where I know that the action group in question is unused.

The answer below is indeed the correct fix for the RasterPropMonitor/KSI MFD/VesselViewer mod bug. But it doesn't fix the but in the ProbeControlRoom for me. I did notice ProbeControlRoom comes with a DefRPM.cfg file but fiddling with that wasn't successful. Any suggestions?

Thats true but for some reason the switching back-and-forth doesn't happen when I type "c" in the kOS console while in a manned IVA. So I thought there's some difference between KSP handles the IVA button and the control room mod does?

I've just tried the Control Room out for the first time... Wow... amazing. Nice touch with the KSP-shaped cocoa foam coffee thingy by the way One question: Is there a way to disable the switching to the control room when I press C? I'm using the kOS console extensively and it is _very_ annoying to flicker between outside and probe controll room while I type tbh. Thanks

Not sure if I understand your question correctly the_bT but you can absolutely run a program that's stored on B from the console of A. If you do a list volumes. you get a list of all "harddrives". Now, important to keep in mind is that the harddirve of the console you have open at the moment is always volume 1. So console A lists itself as volume 1 and console B lists itself as volume 1 as well. That can be confusing at first, so keep that in mind (or use rename volume). In your example, say you have a program called "runme" on the disk of console B. Open console A and type this: switch to 2. // this is the disk from console B run runme. switch to 1. // return back to own disk.

Got it to work by now, all I needed was the node:burnvector to get rid of the inprecissions in my code but thanks a bunch anyway baloan!

Ok thanks.

Quick question about NODE: can it be used to automatically execute maneuver nodes or "just" to set them up?

I just tried that approach... wow... that's much better. Definitely more reliable (although as I said I kinda got my approach to work) and also much shorter. I'm saving over 200 bytes with the flameout-based staging in my ascend script compared to my fuelflow-based staging. Thanks a ton