Dunbaratu

Your error is in assuming there is only one thing that the phrase "x axis", or "y axis", or "z axis" could possibly mean, and that it must necessarily be in the vessels' own orientation. It's not. It's in the coordinate grid of the world space of the game, and it doesn't rotate with the vessel. It's purely a coincidence that you got pitch to work - a coincidence caused by the fact that the planetary north pole happens to be oriented along one of the game space's axes, and KSP just happens to place the launchpad at the equator. Our error (well, not ours, but the original mod author's, who's long gone now from participating and the mod is now being handled by other people), was in calling rotation around these axes by the names "pitch, yaw, and roll" when that's not what they are. (Although to be fair he was inheriting those names from Unity itself which always confusingly uses those terms for any rotation around the axes, regardless of whether or not those axes happen to be being used for airplanes.) Changing it now would break everyone's programs that were already written. I had a longer answer written out addressing every point individually, but then I figured why bother and deleted it. It ended up just being a repeat of what's already in that "bad" documentation you speak of. If saying it there didn't work. why would saying it here make any difference? Here's the summary: (1) If you know what you're doing, then just bypass kOS's own cooked control entirely and use raw control to move the controls to whatever position you want, and take on the responsibility of dealing with dampening things (PID control) yourself. (2) If you want to use cooked steering for only where to point the nose, but then manually override how it chooses to point the roof, look for the thing called LOOKDIRUP(). It lets you pick one vector for your nose direction and a second vector for your "roof" direction". Then look up ANGLEAXIS() which lets you roll any number of degrees around whichever axis you feel like (for example around your ship's forward facing vector).

orbit:velocity is a pair of velocities - orbital and surface (like the two navball modes of the same name). To get the one you mean you need to specify an additional suffix, ':ORBIT', or ':SURFACE". you want orbit:velocity:orbit (imo we really should have called it "orbit:velocity:orbital" not "oribt", but we didn't.) BUT, be warned, that *is* is m/s... but it's a vector, of course, not a scalar. To get it as a scalar if all you want is the magnitude, append a `:MAG` suffix on the end, like so: orbit:velocity:orbit:mag

As far as we can tell, it's because kOS is on .NET 3.5 while the mods it's having trouble with are on .NET 4.x. The methods you're supposed to use to do reflection changed their underlying implementation a bit between those .NET versions. If you use the .NET 3.5 version of those methods to read through something made with .NET 4.x, it throws an exception. Supposedly KSP mods aren't supposed to be using .NET 4.x yet, but something magic we don't understand is happening in the stock game that allows some mods to be getting away with it. The fix is to not attempt to use reflection on the mods who's .NET version is > 4.0 and have the rule that if you want to use kOS"s ADDON system your mod must be using a version of .NET older than 4.0. Everything else @hvacengi was talking about was about finding a good way to accomplish this.

I did this in my auto-landing pilot scripts from some older twitch episodes: https://drive.google.com/folderview?id=0Bxkeai7oN35ffmFzZzZXTXZXWG9kUm5ERjhjR1pLcTBCZVJDX0FtVGltT2QtaUF1TTJqQVk&usp=sharing (There's a lot in there besides just the "follow a heading" but the "follow a heading" stuff is there.) It's basically a pair of nested PID controllers, like so: PID 1 chooses a desired bank angle based on how far off the compass is from the desired heading. The further off the compass is, the steeper it wants to bank, up to a max bank of 45 degrees. PID 2 starts from the output of PID 1, being given the desired bank angle, and chooses the roll control input based on how far off it is from the desired bank.

Minor syntax nitpick. These have to be done with the keyword "is" rather than "=", which was done just to make them consistent with how the existing "LOCAL FOO IS VALUE." syntax works.

You asked the exact same thing over in the kOS reddit group, and it seems to be getting more traction there. (Just mentioning here for posterity in case anyone sees this thread and wants to know where the conversation went from here so it doesn't look like it just died and went un-responded to.)

I always have this problem with stock 2-sided clamshell fairings. I usually just fixed it by going with a 4-sided fairing. It seemed to me like it was related to having a curved thing covering a 180 degree arc wedged in between the fairing ring and the decoupler that did it. Making it cover a smaller arc (by using 4-part fairings so each part is only 90 degrees of arc) seems to keep it from getting stuck.

Wel, yes, but... I mean... if it really is behaving like this is interferes with a lot of things. for example, you can't easily make small interactive commands to try things out. Out of curiosity, what happens when you try using the telnet option? Knowing that might help narrow things down a bit because your keypresses under the telnet option take a slightly different path through the code up to a point, then they're the same as the in-game terminal after that. So if the effect is the same for both, that means the problem occurs after that point, and if it's different for them, then the problem occurs before that point.

Well, I assumed that was the effect, not the cause. (i.e. "I tried to type 'print', and got `^int instead. It's complaining because `^int isn't understood.") Here's something to try: Can you open up any *other* part of the game that has you typing text into a field? For example, put a kerbal in a capsule on the launchpad, EVA the kerbal and have them plant a flag. Try to type some text as the flag's message. Do the letters work right in that input field? I can't think of anything at all that would be causing this weirdness. Did you edit GFX/font_small.png perhaps so the pictures don't match the letters??

(This was RE: kOS name tags) When we added the name tags system to kOS, it occurred to us that we could have made the name tags an entirely independent mod. It's basically just a standalone PartModule plus a ModuleManager config that adds it to each and every part in the game, and what the PartModule does is just so... simple and basic. Pretty much the only reason we didn't was we couldn't think of any reason anyone who wasn't doing scripted autopiloting could possibly want it. ("Okay so I named my part... and??? Why did I want to do that again?") We could try making it separate (and then telling CKAN that it's a dependency for kOS, rather than it being packaged as part of the kOS ZIP itself like it is now). Then people who are doing a mix of kOS and kRPC could have the same name tag used for both, instead of having to set two different name tags under two different PartModules to do it. Does this idea interest you?

We've never heard of this happening from *anyone else*, ever. This is really strange. What kind of keyboard do you have? Is it one designed for non-English language, in which the key layout isn't the common "QWERTY" style but is something else? (I sort of hope not, because if it is, there's going to be just about no way we could reproduce it ourselves to figure out how to fix it).

Not true. Period at the end of a bracketed section is optional.

For this reason I plan to not have the background music I usually have when I stream. I want the recorded video to be un-muted for people who have to watch it later.

What's off is that I originally typed in my time in my local time zone as 16:00 UTC-5, then decided it was better to just post the UTC time, so I converted it to 21:00 for UTC, but then neglected to change the label from "UTC-5" to just "UTC". Add to that the fact when I composed the message yesterday and saved it as draft, I was planning on a different start time and when I changed the start time to the one I went with in the end, I didn't edit all the cities' times to match that edit. In the end it was an inconsistent mess. What I meant was this: I live in UTC-5, my local time is going to be 16:00 when I stream. That will be 21:00 in UTC+0. I've edited and corrected the post now. Thanks for catching it.

Twitch devs show kOS v1.0.0 UTC time 2016-07-08 21:00 (Friday) Stream Channel: https://www.twitch.tv/dunbaratu With kOS v1.0.0 coming up Real Soon Now (tm), we decided to do a stream on Twitch of new things, with an eye toward Q&A about it. Come along and see what important things are changing and have a chance to ask about it. We intend this to be timed very close to the release of kOS v1.0.0. The release might go out just a few hours before, or just a few hours after, the stream itself. In any case the release is expected to be roughly co-incident with the stream. Unlike the release, for the stream we figured it was more important to announce a predictable time ahead of time (thus this message) because it's live interaction. With the actual release, well, it comes out whenever we happen to have gotten all the last pieces in place (changelogs, documentation updates, etc). This is in no way a binding promise to get the release out at the expected time!! Who knows what might be found in those last few hours of work before it goes out. It could be something that is a showstopper. We'd LIKE to get it out at the same time as the stream. We don't PROMISE to do so however. The stream will be broadcast here: https://www.twitch.tv/dunbaratu And include at least 2 of the devs on microphone: Dunbaratu (Also known as Steven Mading here on the forums, AKA "me") Hvacengi The duration is unknown. It depends on questions and interaction.

Delete the word "wait" from the loops like this: wait until altitude > 2000 { lock steering to up + R(0,-60,180). } so they become like this: until altitude > 2000 { lock steering to up + R(0,-60,180). } The command "wait until" isn't a loop header. It's just a single line statement that says "the program will do nothing and be stuck on this line until the condition is true." The command "until", on the other hand, is a loop header. That being said, there's some other problems in the code, but you haven't encountered them yet because of that syntax error. When you get rid of those syntax errors, you'll run into the following issues next: (1) constantly re-running lock steering: There's no point in (and it's actually detrimental to be) re-running the lock statement again and again inside a loop if you're not actually changing the formula you're using. The whole point of "lock" is that you give it a formula and it can re-run it when it needs to. When using lock steering, re-running the lock statement again and again essentially turns kOS's PID controller into just a dumb "P" controller, since you keep telling it to make a fresh start with a "new" steering formula, so it clears its memory of how it's been behaving under the "old" one. (It doesn't realize the "new" and the "old" one are identical and it didn't need to do that.) (2) busy looping fast without an explicit wait: The loop you are trying to run, not only re-locks the steering again and again unnecessarily, but also pointlessly re-executes it *multiple times per game-engine update*, even though it can't have any effect until the next 'physics tick' of the game engine anyway. Usually when you do have a loop like this, you want to explicitly allow a 'tick' to pass in between iterations by inserting a 'wait 0.' (wait the minimum possible wait time, which is just until the next 'tick'.) into the loop body. But that being said, I only mention (1) and (2) for your future information in situations where you do use loops, because what you *probably* really want to do in this specific instance is just get rid of this loop entirely and turn this: wait until altitude > 2000 { lock steering to up + R(0,-60,180). } into this: lock steering to up + R(0,-60,180). // no need to loop this - it will keep being re-run in the background by the kOS steering manager. wait until altitude > 2000. // just do nothing and sit here until the condition is true.

When you get this error (key was not present in the dictionary) and you get it being done by ProgramBuilder.ReplaceLabels() as shown here, there's a good chance it's not your fault and it's a bug in how things are being loaded into the VM by kOS. We've done a lot of overhauling in that area in recent developer work so I can't tell if this problem would still exist in the next release or not unless I can re-run exactly everything you're doing in exactly the way you have been running it. That would mean, starting from the same saved game, running the same program, the same way, on the same craft. Some of what your program is doing looks like it's dependent on having a craft that is exactly like it expects it to be, with the same parts on it. (Which is why I'm reluctant to give it a test. It's a lot of set up work for a problem that for all I know might already be fixed.) The code change under the hood that may or may not have already fixed this in the development version is this one: https://github.com/KSP-KOS/KOS/pull/1657 The old way the RUN command was implemented before that had some odd failure cases where it would crash the ProgramBuilder.ReplaceLabels method. If you aren't in a position to be able to compile the kOS C# code yourself, I could try to give you a temporary ZIP file you can try to use to re-install kOS and it would give you the development version as-is (possible problems and all), and it might let you test if you still have this problem or not. I'm a bit reluctant to do this, though, as I don't think we're that far away from having a more official proper release anyway, and spending time on this problem would detract from getting that release out, which might fix it anyway.

Are you sure? I've been doing exactly that in my own scripts and it has worked. This isn't very descriptive. If it's a bug, can you describe its behaviour more clearly (what's the error you see? What is arctan2 doing that is different than what you'd think?), since it's not a bug we've seen, and we can't fix what we can't see happening.

If it was easy to be sure we had all the places where kOS values were sent to KSP and be 100% sure we had them all, we wouldn't have needed the "no Infinitys, no NaNs" rule in the first place. Many, many places in kOS send values to KSP, and we don't have the resources to go and find them all, then test each and every single one of them to find out which ones are not protected against in KSP's own code. Especially since it can't be done with automated unit testing either since many of these cases depend on the game being in a certain state (i.e. for this test you have to be in orbit, for that one you have to be landed, for that one you have to be under accelleration, for that one you have to be coasting, etc etc etc). And before you say "why not just try/catch them?" the problem is that if we don't wrap small try/catches around everything, and instead try to catch them all in one universal try/catch, then it also interrupts the behavior of our VM and we don't get to control the state of our own data and make sure it's right. (i.e. we stop right in the middle of trying to do the work of an opcode, and didn't finish updating all the VM's state.) This is why exceptions in kerboscript aren't currently a thing. When we throw exceptions and catch them in one universal location, the easiest way to get our own VM data back to a known working state despite work having been left half-done is to just kill the kOS script program entirely. To implement kos exception handing, we'd have to keep a checkpoint of the entire state of the VM as it was just before embarking on starting work on the current Opcode, and then return to that state again if a script traps an exception that happened in the midst of trying to execute the Opcode.)

It's a known bug - 1.1.3 altered the arguments to the warp function so it needs 1 more than it used to. (Ironically, in the source code form, it doesn't *look* like it needs one more, because it's a defaulted argument, but the way defaulted arguments work in pre-compiled languages like C#, the caller needs to be recompiled to supply the default arg even though the source code looks no different. Code compiled before the default argument was in the method's definition doesn't end up populating the default arg.) The problem is that 1.1.3 came right when the development code was in a state of flux. It's not easy to *just* release one change and one change only to fix that problem There's other stuff tied up in there that isn't ready yet.

It's just the standard KSP log file that comes from Unity - the sample place where everything else in the game goes. For some inexplicable reason I just do not understand at all, Unity puts the standard log file under different names in different places on different OS's (even though it doesn't have to for any real OS reasons, and it claims the whole point of Unity is to be cross platform). Here's where to find it depending on your OS: Windows: (where-ever-your-KSP-is-Installed)\KSP_x64\KSP_x64_DATA\output_log.txt , if running in 64-bit mode. (remove the "_x64" parts if you run in 32-bit mode). Mac OSX: ~/Library/Logs/Unity/Player.log Linux: ~/.config/unity3d/Squad/Kerbal Space Program/Player.log (There's no reason the Windows version couldn't also have had it in the user's own home folder like the Unixes do, but for some weird reason, it doesn't. And for some weird reason it uses a different filename ("output_log.txt" vs "Player.log").)

I did all my testing in sandbox. I just played in career and realized that the tech tree nodes are kinda backward. You unlock the high-tech lasers before the low-tech ones. Gotta fix that.

TLA - Three Letter Acronym. As in "Can somebody explain to me what this TLA means?"

A kOS WAIT command is incapable of waiting less than the duration of a single physics tick. If the wait conditions are such that the wait should take less time than it takes to get to the next physics tick, the duration of the wait ends up being effectively "rounded up" to the start of the next physics tick. In fact, this means you can even say WAIT 0. in place of WAIT 0.01 and it will end up doing the same thing. The moment you WAIT, you are "yielding" the remainder of the current update's slice of time and telling the system to check during each subsequent update to see if it's time to continue or not. At minimum, regardless of how small the WAIT duration is, or what the boolean condition of a WAIT UNTIL is, it can't notice its time to continue until the next update checks again. Or to put it another way, "WAIT cannot resume halfway through a physics update. All WAIT durations end up rounding up to the next nearest start of a physics update."

As far as I can tell, it seems to be impossible to make two different instances of the same PartModule class end up having two different min/max ranges for the same UI slider on the right-click context menu. It's acting for all the world as if all instances of the PartModule must share the same min/max values and whichever instance happens to have altered them most recently, those values get used from then on by all the other instances too. (in other words, it's behaving exactly like static member fields on a class would). Here's an example of how I'm trying to dynamically change the min/max range values at runtime per-instance: It does this by reading the values from the part.cfg file (so instances of this PartModule for different parts can have different settings for the range allowed on the slider), and applying the value to the slider, like so: BaseField field; DebugMsg("LaserDist is trying to config GUI panel fields from settings:"); DebugMsg(String.Format("Part name = {0}, MaxBendX = {1}, MaxBendY = {2}", part.name, MaxBendX, MaxBendY)); field = Fields["BendX"]; ((UI_FloatRange)field.uiControlEditor).minValue = -MaxBendX; ((UI_FloatRange)field.uiControlEditor).maxValue = MaxBendX; if( MaxBendX == 0f ) { field.guiActive = false; field.guiActiveEditor = false; } else { field.guiActive = true; field.guiActiveEditor = true; } I verified that it is indeed seeing a different value for MaxBendX for two different parts, and is indeed running the code above two different times once for each part, and that it is indeed storing two different values for the *other* properties of the field "BendX" just fine - i.e. the guiActive and guiActiveEditor boolean flags *are* indeed behaving differently for the two different instances. If I set one of them to have a MaxBendX of 0 and the other to have a MaxBendX of 15, then it *does* hide the one with a value of 0 just like the above code shows it trying to do. But when I try to make them both have a nonzero value for MaxBendX, but a different nonzero value from each other, I just can't seem to force them to have different settings for max and min. If I set one partA's MaxBendX to 15 in the part.cfg file, and set partB's MaxBendX to 20 in its part.cfg file, then either *both* end up having ranges from -15 to +15 on their sliders, or *both* end up having ranges from -20 to +20 on their sliders. Which one I end up with seems to depend on which part KSP loads last. I proved this by changing the names of the parts to make them get sorted differently, and thus get KSP to load them in the opposite order. If partA loads last, then both partA and partB have a range of -15 to +15. If partB loads last, then both partA and PartB have a range of -20 to +20. I can't get partA to go from -15 to +15 and make partB go from -20 to +20. Is there a way for me to break out of this static-like behavior of the minValue and MaxValue so I can make them differ or am I just stuck?