Dunbaratu

It doesn't support subdirectories. Everything has to be Gamepath\Ships\Script\*.ks.

Define "nothing seems to work". Its impossible to diagnose without being told what you're seeing when you try.

Toggle on, then toggle off, matching the boolean state of the action group variable, would be the most sane way. Otherwise it cannot sustain fire. (If it turns the gun on for each edge condition from false to true or from true to false, it doesn't know how long to keep it on after each state change, and has to choose to turn itself off when it feels like, i.e. firing fixed-duration bursts). It's better to just go "hit the button once to start gun, again to stop gun", which is how the stock action group system is designed to work. - - - Updated - - - A kOS script cannot click a mouse button. You can't chain a mouse button click with other actions on the craft like you can with action-group-able activities. You can't chain a mouse button click effect to other effects using SmartParts like you can with action-group-able activities.

Streaming isn't like live TV. It's like live improv. The difference is in whether it's a one-way or a two-way medium. If you think streams need to be treated exactly like pre-scripted live TV, you are essentially saying the streamer should pretend the feedback chat doesn't exist.

and I am of the opinion that streaming is a very different animal from a pre-planned and carefully edited video. You should expect a much looser, less organized and concise flow from a live stream, because an edited video can trim the cases where it failed, or cut it down to the most impressive example of a thing. And it can skip over mundane steps that aren't really part of the subject mater at hand. (i.e. in a youtube video, you can have something hat goes "Here I build the rocket, start to launch it, and ... let's just jump cut to the point where it's done launching and is in orbit. Okay now let me show the the thing I was going to show...". A live stream doesn't allow for that sort of editing out the busywork. Therefore I think being less organized and concise should be a bit more tolerated on a live stream. The point of a live stream is that you're watching a person *as* they go through the steps, failures and missteps and all.

This would be a very hard problem to solve without very hard math (likely differential equations), because Kerbin has atmosphere. On a world without air it would be easier to predict.

It looks like this bug: https://github.com/KSP-KOS/KOS/issues/1117 Maybe. Is there a FROM loop with a lock throttle in it? If so, try re-writing it as an UNTIL loop for the temp workaround. It's fixed in develop, but that's not released yet.

Not true. I'm referring to the craft parts that you add to the vessel, that definitely exist in sandbox mode too. And for kOS, those parts are needed to get any kOS functionality at all, sandbox or career, unless you mess with a ModuleManager hack to add a kOS computer to a stock part. At any rate, the description has been edited to remove the problem now.

That's not really true. It uses its own steering mechanism that is just as poor as KSP's stock one, but it isn't *actually* using the same code as the stock one unless you use the SAS steeringmodes like set sasmode to "prograde".. It actually is sharing the same code as RT's flight computer uses, although that won't be true anymore on the next release. - - - Updated - - - The output_log message that accompanies that screen message will have the more detailed description, more verbose than what's in the terminal screenshot. Can you post that?

This is confusing: Because KER, MJ ,and KOS *do* in fact add parts, so it's hard to tell what you're actually calling disallowed if you think they're fine but don't want mods that add parts.

The next kOS release "any day now" has better LOCK STEERING behavior - waaay better. But in the meantime, one suggestion I always have is this: Have you ever been slightly annoyed that stock KSP puts your rocket on the launchpad such that when launching to the east, as you typically do, you have to YAW rather than PITCH to do so? (i.e. press the "D" key rather than the "S" or "W".) Well actually that's related to this common problem in kOS. kOS, when trying to aim UP is also trying to roll into its default orientation, which isn't the one that KSP puts you in by default, and that roll right off the launchpad confuses it a bit as it tries to wind its way around to the desired situation. So try this first before trying anything else: In the VAB, grab the root part with your mouse (such that you're now moving the whole vessel, leaving behind no detached pieces). Then rotate the entire vessel by 90 degrees so its bottom is now facing east, and its top is facing west. (I cant remember if this is the "A" or the "D" key that you want to use, but basically make the roof of the craft aim toward the back of the VAB and the belly of the craft face toward the big open warehouse doors.) Save it like this and launch it. If you've done it right, the navball should show, when still on the launchpad, that the "north" red line is now to your right, rather than on top as it usually is). If you start your launch from this position it might reduce the initial roll quite a bit. I may have gotten the above orientation a bit wrong - try it again rotated a few different ways if it doesn't work the first time. KSP has a really annoying bug in the stock game, that kOS inherits and makes it look like it's kOS's fault when it's really the stock game's fault. This bug is when it comes to calculating resources in the current stage. To see if you are having this bug, click the resources window open in the main KSP toolbar and then click the checkbox for "stage only", which changes the display to showing only the resources in the current stage. Leave this window open as you launch the rocket and watch what it's showing for liquidfuel. If it shows lots of liquidfuel left when clearly you have no liquidfuel in the current stage, that's the bug. What it's doing is failing to realize that the fuel in some of the other tanks are for different stages - it's adding them to the current stage when it shouldn't. kOS is passing this bug on to you when you do STAGE:LIQUIDFUEL. (And the annoying thing is that kOS used to calculate stage values itself in older versions, and it was changed to just believing what KSP tells it because we *thought* that would be better than doing the work ourselves. At any rate, I expect the bug won't last much longer since KSP is revamping so much in 1.1.) If this is the problem you're having there's a few workarounds: 1 - Redesign the staging list to ensure that the decouplers and the engines are in different stages. Having a stage where it does a decouple at the same time as it activates an engine seems to be what triggers this bug. Having two different stages, one where it decouples, and the next where it activates the next engine, seems to help avoid the bug. (Exception - If you have launch clamps - DO put those in the same stage as the first engine - don't fire the launch clamps before the engines are lit or it will fall to the launchpad.). or 2 - Change this: when stage:liquidfuel < 0.0001 then { to this instead: when ship:maxthrust = 0 then { So it will just never bother using the buggy stage:liquidfuel check at all and instead base the check on the fact that the engine is flamed out and has no thrust. In fact if you do #2 , you can even remove the "until" loop that follows, entirely. And yes, the tutorial is dated because it was written before this stage:liquidfuel bug manifested. It's been re-written already but the new version won't show up until the next time kOS has a release (real soon now???).

From your first post, I'm not sure how helpful kOS is for you in this instance (I say this as one of the developers for kOS). Basically, Mechjeb is an autopilot that already knows how to play the game and can even be used to teach you how, by example. Whereas kOS is entirely the other way around. It's an autopilot where you're supposed to teach IT how to play the game. (It lets you make your own custom autopilot, rather than providing you with a one-size-fits-all working autopilot out of the box). That being said, It's amazing how much you *do* learn about how to pilot a rocket when you attempt to automate it. It forces you to notice what you're doing and transform subconscious actions into conscious ones.

I'm sorry. I was defending WHY it was so easy for us to miss it (all kOS devs who read your report missed that vital point, not just me). There have been cases in the past of people being unaware of the CONFIG:RT option entirely, and therefore issuing a false bug report based on them not realizing it's there. But in your case you knew about enough to talk about it in the bug report, but talked about it with an inverted understanding of what the flag means. Yours is the first case of someone being aware of it but getting its meaning backward, which is why it was easy to miss that you were describing its effects backward and that this was the actual source of the misunderstanding. You're the first person who has *had* that misunderstanding, which is why it was easy not to notice it. It's not something we've encountered before. I'm sorry for being a bit snippy. We're in crunch time, have no idea when KSP 1.1 will drop because they never tell anyone ahead of time, and with everyone having limited free time there's a bit of a worry about getting things out in time to be ready for all the work that 1.1 will require. Into that environment someone comes along who issues a bug report that consumes hours of work because what it seems to be describing would be quite severely broken - a major major enormous flaw in kOS - if it was truely broken. It is very frustrating to find out after wasting those hours that it was an invalid bug report all along, due to a misunderstanding on the part of that user as to what a flag means - a misunderstanding that was unique to that user and that user alone. So yes I shouldn't have been as dismissive as I was, but for your part you should be aware that that was borne of the frustration of your "bug" report causing me to waste a few hours of work I could have been doing something productive with on the mod.

Okay, sorry about that. It's easy to miss since you're doing something no other human being wants to. kOS has to go out of its way to prevent RT from imposing the delay. kOS isn't causing the delay. RT treats all attempts to move the controls as if they came from the human pilot by default, unless a mod explicitly tells RT "This particular control movement isn't human, so get out of the way and allow it to work" in a sort of inverse captcha. As an experimental feature, it doesn't just try to autodetect RT to enable the experimental code that tells RT to get out of the way. When the feature stops being experimental, the user ability to toggle the flag will go away and it will get turned on only by trying to autodetect RT. Once upon a time the feature didn't work well, and trying to autodetect RT was a problem anyway because there were multiple versions of it floating around, and not all of them used the same API for the "inverse captcha" call I was talking about. It was considered better to just let the user tell us that they need the RT support turned on than for us to rely on the autodetection. Eventually, that will go away and you won't be able to toggle it off if we detect RT has been installed. There's no longer two different versions of RT, and the code in RT to allow robot pilots to sanction themselves has settled down and become consistent, so it will probably go away after the next release.

Not quite. The thing you keep missing is that the line of code to print words to the screen and the line of code to move the steering were *adjacent to* each other in the program, with no conditional branches or anything between them, and nothing that depends on signal delay occurring in between them. Therefore if there's a delay between the print command and the steering command that comes immediately afterward, that would be a problem. The 65 second delay should only occur when the program starts, or when the action group is pressed, but this delay was in between two *adjacent* commands, AFTER the triggering had already happened. Regardless of how the triggering happened, or how "cheaty" a technique was used to do that, once it does trigger, the two *adjacent* commands should have happened right away back to back. That would still have been a bug had it not been merely caused by turning RT support off as was later admitted. Probably. Gaiiden just wasted precious developer time when we're trying to get our last changes merged in for a release before KSP 1.1 drops, which does irk me. I'd be more sympathetic had the flag been off by accident, because it's easy for new users of kOS to not know what it does, but he clearly knew what it was for and turned it off deliberately to attempt to get that sort of halfway enforced RT in the same game that nobody else wants, and then had forgotten that it was off. That being said, wanting to disable RT's rules (entirely, not just signal delay) for some saved games on the same installation as the saved game where you're using it for career is entirely legit, and RT refuses to support that either, which is annoying. (i.e. the stock game doesn't say that just because you are using hardmode on one saved game that you have to use it on all the others too. Having a second saved game for experimental sandbox play is entirely legit and within the game's intended play style, and RT makes it a real pain to do.).

In this case I'm going to close the issue you made on github for it.

small hint: This: IF eng:flameout = true { is redundant because all Boolean values work that way without the '= true' tacked on, as follows: IF eng:flameout { eng:flameout already *is* a boolean expression by itself, because it's a boolean variable that can be false or true, just like an expression with '=' can be false or true. In fact, depending on what you're doing, it's usually a good habit to avoid any boolean expression where you're doing "= true" or "= false", for this reason: It works fine when using a type that is restricted to only being allowed to be two enumerated values: 0 which is aliased to "false", or 1 which is aliased to "true", like a Boolean tries to be, but given that you can make a Boolean interpretation of any integer value, doing "= true" gets wonky results when the value in question is, say neither a 0 nor a 1, but say a 2. By the rules of Boolean logic, anything that is not zero is true, so a 2 should be a true value. But the check "foo = true", if foo was 2, would yield a false, which is wrong. Granted, this isn't a problem when you put the burden on the language to restrict the values to only being capable of being 0 or 1 and nothing else, but as a general programming practice, it's best to avoid it so it doesn't mess you up when you come across more low level languages that don't do this coercion and really treat all boolean expressions as integers (like C or C++ for example). Plus it just looks weird to redundantly say "= true" when that's what the Boolean value already meant by itself.

What's a "BFS plugin"? Is there some other mod called BFS that this depends on?

There should be a delay for STARTING the script, but not a delay once it's running. The delay reported was a delay occurring after the program had already been started (after the 65s lag had already passed), in between two consecutive statements of the program (the print statement, then the next statement tries to move the controls, which instead of happening right after the print statement, happens 65 seconds after the print statement). This is not normal behavior, but it's a difficult problem to reproduce. In simple tests it works fine, so there's got to be something very specific happening to trigger it that isn't clear what it is. If this is what it did normally by default when we try using it, that would have been noticed immediately and prevented releasing it.

There should be a status line added to the menu for it's current state, you're right there. But I'm not going to remove useful information just because everyone else does.

I disagree. You shouldn't have to turn on a device to learn how much power it uses. You don't have to actually turn on a light to find out that it uses 40 Watts - you can just read the label.

In general most people seem to circularize with some variant of getting periapsis and apoapsis altitudes within a tolerance of each other, but that's frought with error - if you take too long to burn, it can be the case that it's actually impossible to do this and the script fails to realize that you've already done the best you possibly can and it's time to stop trying. This very simple bit of code does circularization sort of okay: // Number of seconds you want to start the burn before of the apoapsis. // There's precise ways to measure this, involving the Tchaikovsky rocket equation, // but for a first go, just hardcode it depending on your ship design: set apoapsis_lead_time to 5. lock steering to prograde. lock throttle to 0. wait until eta:apoapsis < apoapsis_lead_time. // Thrusts until the apoapsis and periapsis have started to swap positions with each other, // i.e the ship is in the half of the orbit that is closer to Pe than it is to Ap: lock throttle to 1. wait until ship:obt:trueanomaly < 90 or ship:obt:trueanomaly > 270. lock throttle to 0. print "That's as good as it gets. I should now be halfway between apo and peri.".

It's things like this that make me reluctant to go "no-revert" mode. Not all failures are the player's fault because the game has a few buggy behaviors like this one. The timewarp simulation is incorrect when there's atmosphere, and it's supposed to drop you out of time warp at the edge of the atmosphere, but it often doesn't. What happened here is physically impossible - you wouldn't be going that fast that deep into the atmosphere if the game had been calculating atmosphere correctly all the way down to that point - it would have slowed you by then. The reason it didn't calculate it correctly is because it doesn't do it right when under time warp, and for this reason it's supposed to drop out of time warp when atmosphere is encountered, but it often doesn't do it soon enough to avoid its own miscalculations. This isn't your fault. It's an error that exists purely in the game's simulation. Granted, there is a workaround, which is "don't let the game drop you out of timewarp itself - do it yourself before you get close" - but the existence of a workaround for a game bug does not transfer the blame for the bug from the game to the player. It's still the game's fault, first and foremost.

When SAS is in pure "stability" mode (the "lowest tech" version of SAS, not the more complex modes you get later), it tends to reset itself over time to the new attitude. Even if you do get SAS fighting you at first when you go up a hill, after several seconds, it will become reset to the new uphill attitude, and in fact fight you when you start to flatten out again. The idea that because you set it when you were on the flat, it will forever be holding you to that flat isn't how it works in my experience. It will only fight you for a few seconds, and then it will have been reset to the new attitude it's been having for the last few seconds. THink about what happens when you're in space with SAS on, and you pitch up manually with SAS on, using the 'S' key. You can fight the SAS and force it to pitch up, and after you let go... does it rotate all the way back to where you stared? No. It tends to stick to its new attitude. SAS will have the effect you're talking about, but only for a second or two before it starts to adhere to the new attitude it's been at. You can also force a reset even faster than that by turning SAS off and on again quickly. Turn it off right at the base of the hill, turn it back on again after you pitch up to the slope.

You don't hardcode how many cores to use, but using more than one thread lets the OS put some of them on other cores if it thinks that spreads the load better. When it's single-threaded you prevent the OS from being able to do that. When you write threaded code and don't hardcode how many cores to use, the OS can still choose to run the threads on on multiple cores if it wants to. There are cases where forcing it to pick certain CPUs is beneficial, but even if you don't do that, just making it multithreaded *allows* the OS to make it multi-core if it wants to. If your program has N threads, then the OS won't use more than N cores to run it. It can't. Single-threaded therefore also means single-core.