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!

I've tried searching but I must be looking in the wrong places because I'm coming up empty. Can anyone tell me how to access the individual components of the velocity vector? Or alternatively if there is an "orbitalspeed" equivalent to surface speed that would work as well. If you need context for what I'm using it for, here's what I'm attempting to do: wait until eta:apoapsis < abs(2287-<orbitalspeed>)/(maxthrust/mass). If I can access the individual components of "velocity" I figure I can just SRS them to get orbital speed.

I suppose this is a somewhat "un-kerbal" suggestion. I guess I just don't like seeing Kerbalnauts die needlessly. Maybe I'll just have to build my own shake table with infernal robotics...

We've all had problems with wobbly rockets or payloads before, and there have been many suggestions before to stop it. However, I'm not suggesting we stop it, just that we get the chance to test for and fix it with struts before we actually launch the payload/rocket. This would be especially useful if the idea of rockets damaging buildings at the spaceport ever gets implemented. My thought is that it could be done in a similar way to Maybe put a shake table inside the new R&D facility?If this has been suggested before, I apologize. I searched through the already suggested ideas and this subforum for words like vibe, shake, and table and found nothing similar to this.

Seems to be working with no modifications. Just dump it into the correct directory structure like so:

Nice work! I'll edit the leaderboard when I have access to a computer that hasn't blocked these forums or when my phone isn't nearly dead. Though I might have to add a second leaderboard for "almost didn't cheat" scores Edit - updated the leaderboard, although I got calculate slightly different scores when I plug your A&P into my spreadsheet (probably just roundoff in your altitude numbers?) I've used my calculations for consistency moving forward.

Nope, that undermines the point of the challenge (powering straight to orbit). All powered flight should be done with a TWR>0.5 relative to Kerbin sea level. I'll edit my rule for clarity.

You may cut your engines. Just keep in mind that once you do, you either have to dump the stage and light the next, or (hopefully) be in orbit. I was going to originally only allow one "shutdown" event for the whole flight, but I sees no reason why earlier stages couldn't be shut down and discarded early. Though if people start abusing that combined with the "two seconds to light the next stage" to coast I may have to adjust the rules. The main reason the two seconds is there is so people have a bit of time for radial stages to move away.

The Challenge: Achieve a 100km circular orbit with continuous full throttle until engine shutdown. (Jeb is not a patient man) Leaderboard: Respawn - 59.517 (117.333 x 90.994) soranno - 42.264 (146 x 113) - Almost Didn't Cheat-erboard: soranno - 57.611 (156 x 147) - - The Rules: Stock parts + Kerbal Engineer Redux (recommended, but not required) only, no MechJeb, no .cfg edits, no anything else No debug No RCS thrusters (though you may use tanks as ballast if you wish) No coasting between stages (<2 seconds between burnout/shutdown of one stage and ignition of the next) You may not reignite any engine (you may shut them down, but if you're going to light another afterward it still needs to happen within the 2 seconds from the above rule) Minimum thrust-to-weight ratio is 0.5 relative to Kerbin sea level for all powered flight (As I said, Jeb is not a patient man) You must be able to view at least part of the prograde marker on your navball at all times while under power (no "spin until apoapsis", but still allows sharp turns) The Scoring: Scores will be determined by the following equation (kilometer units): 3/(eccentricity + 0.03) - 0.5*abs(100 - (apoapsis + periapsis)/2) Or, if you only have apoapsis and periapsis data the equation can be written as (again, kilometer units): 3/((A-P)/(A+P+1200)+0.03) - 0.5*abs(100-(A+P)/2) Note that negative scores are definitely possible and nothing to be ashamed of, burning straight to any orbit is an achievement! Exmple scores: 100. for a perfect 100km circular orbit 97.4 for 100 x 99 78.2 for 100 x 90 45.6 for 125 x 75 75.0 for 150 x 150 (it's better to be circular than dead on for altitude) 0 for approximately 214km x 100km To get things rolling, after about 15 attempts, here's my best thus far: 162.575 x 82.4, Score: 23.85. The images are large, so I've linked rather than imbedding: On the Pad - After MECO. If this is a repeat of a another challenge please let me know. I did a search and found nothing, but I could have just searched poorly.

Huh. Didn't realize there was a hard limit set for that. Now it all makes sense. Thanks!

In theory, couldn't one raise his/her apoapsis enough to get a munar assist to a true orbit?