mileshatem

I see your point, but I'd argue that extending burn times past their rated time is a bit more doable in real life than with TestFlight. For ablative cooled designs there would be a hard cutoff time, but it'd probably be a good bit after the "rated" burn time due to design margin. Though I suppose the TestFlight rated time could be simulating the zero-margin time for the engines instead. For regeneratively cooled designs, once they reach steady-state operation there's a lot less stress on the system and they should be able to fire a good bit longer than the standard duty cycle, which is why you can test fire the engine for a full duty cycle, then later use it again for another full cycle during launch. But either way, now that I understand the mechanic of the mod, I can work with it. I just was expecting the rated times to increase and thought I was having an issue because they wern't. Thanks for the help everyone.

I see, so it seems like the engines are rated to a burn time, and as you collect more and more data, you're more likely to get to that rated burn time? And once you have lots of data, you might even exceed it a bit, but typically not by much since it seems like the momentary failure rate begins climbing rather rapidly as you approach and exceed the rated burn time. I guess I was hoping that as you got more data for the engines, the average useful burn time would increase as well, mainly because the early game engines all seem to be rated to 1-2mins, which isn't all that useful for anything but sounding rockets. I suppose I need to research better engines. Anyways, thanks for the help.

Quick question regarding RO with TestFlight: should my engines "Rated burn time" and "Current reliability" increase as I collect more and more data? I've got nearly 7700/10000 data on my AJ 10, but the reliability isn't increasing (still at 460s MTBF, 1m55s rated burn time).

Am I remembering correctly that KJR works off node sizes for parts when it's calculating how much to reinforce them? I'm trying to debug issues with things falling apart for a very heavy (500T to orbit) launch vehicle in RSS and have noticed that it's always my 14m diameter procedural tanks that break first. From the looks of it, procedural parts stop scaling up their node sizes at size 3...

Absolutely love the mod, amazing work! One quick question though, is there a way to disable keypresses from toggling the IVA? As a kOS user, it's kinda annoying to have the view switch as you're typing a command in the kOS window.

That would be the very simple thing I was missing. Thank you!

I must be missing something very simple, but I've been banging my head against this long enough that I'm hoping someone else point out the obvious. I want to calculate the angle between my active ship's facing and a maneuver node. The problem is that node:burnvector returns vector format, and ship:facing returns direction format. And as far as I can tell, there's no alternative for nodes which will return a direction, or for ships which will return a vector. I'm hoping I don't have to manually convert from one to the other, but if I do is there a wiki page or something someone can link me to on how to do that? Thanks.

The problem with that would be if you have multiple modules on the same ship. Which one should it open a terminal to? Almost all of my ships have at least two kOS modules on them, one on the launcher upper stage and one on the payload, that way my launch script can run on my upper stage and deorbit it after releasing the payload. To solve your accessibility-for-right-clicking problem, I'd suggest setting an action group for it.

I'm guessing this is more of a KSP-returning-the-wrong-value bug than a kOS-interpreting-things-wrong bug, but I thought I'd mention it just in case it's the other way around. Also I apologize if this has been mentioned before. I searched through the most recent dozen or so pages of this thread and didn't find anything. When querying maxthrust for a vessel, it's including the potential thrust for my now burned out sepatrons (ullage) along with the main engine thrust. If I do the same calculation for an identical vessel without the sepatrons having been fired, it correctly reports the main engine thrust only. It sounds like kOS's maxthrust is then the sum of thrust of all active engines (i.e. showing a fuel bar) and doesn't ignore fuel-deprived engines.

Just a heads up, there's a shift that somehow works it's way into the "MM Formula" column in the spreadsheet you currently have linked (see row 19 and row 20 for example). You should just need to copy the formula from the top cell all the way down again to fix it. And thanks for putting this all together! You made my life tons easier today since I was about to try and do it myself. Being able to start from this meant all I had to do was tweak the things I wanted tweaked.

Edit is currently broken. You'll want to use your favorite text editor to edit the archive files outside KSP and import them to your ship's computer (or switch to the archive)

That's my understanding as well, which is why I thought it might be nice to have a workaround (albeit very crude) by just toggling the "remote tech integration" setting actively during a script so you can use action groups while it's off and throttle and steering while it's on

I'm guessing RT integration is not something that's toggelable on-the-fly and it needs to be set before KSP loads? I ask because with it off, kOS can run action groups without a connection, and you're saying that with it on it has access to throttle and steering. So it could be nice to switch back and forth to get something simulating full control. Maybe I should just wait until the full RT has it's path forward and RT integration is worked out...

I've spent awhile trying to figure out why I couldn't set a maneuver node properly with kOS, to finally figure out that the documentation in the readme on github is a bit off. It seems that TIME does return a value of universal time, but kOS doesn't consider it to actually be a "number". To clear up the confusion in the documentation, the changes I think that need to be made are: In the "NODE (universalTime, radialOut, normal, prograde)" there's the line: SET X TO NODE(TIME+60, 0, 0, 100). I believe that should be changed to: SET X TO NODE(TIME:SECONDS+60, 0, 0, 100). A similar error is under the command reference > add section I don't have a github account to request to make a change, but if that could be fixed at some point it'd probably save some people the debugging trouble I've gone through.

Ah! Everything I was finding said that VELOCITY was the orbital velocity vector (which it also appears to be), and that you could do :MAG to get the magnitude of a vector. But when I tried doing VELOCITY:MAG it failed (along with VELOCITY:X etc.). Didn't realize I needed the :ORBIT in there, thanks!